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ABSTRACT 


Complex  visual  simulations  can  strain  the  capability  of  a  single  workstation.  A  mix 
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made  between  broadcast  and  direct  connect  protocols. 
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I.  Introduction 


The  Graphics  and  Video  Laboratory  of  the  Department  of  Computer  Science  at  the 
Naval  Postgraduate  School  permits  the  researcher  to  create  three-dimensional  visual 
simulations  from  digital  terrain  data  [Ref.  1].  Specialized  graphics  hardware  allows  the 
display  of  such  simulations  in  near-real  time.  The  goal  of  a  good  part  of  the  work  in  the 
lab  is  the  creation  of  a  movie-like  view  of  movement  over  and  on  terrain,  with 
increasingly  complex  movement  animation  models.  Such  projects  have  strained  the 
equipment’s  capabilities.  One  method  of  increasing  available  computing  power  is  to 
harness  multiple  heterogeneous  machines  together  in  some  distributed  computing 
organization.  It  requires  communication  between  the  various  machines,  as  well  as 
carefully  matching  each  machine’s  capabilities  to  its  assigned  tasks. 

A.  PROBLEM 

Rapid  turnover  of  inexperienced  students  at  the  Naval  Postgraduate  School  makes 
the  creation  of  complex  simulations  difficult  to  manage.  The  learning  curve  becomes 
steeper  as  the  lab’s  capabilities  increase.  One  of  the  areas  of  difficulty  has  been  inter¬ 
computer  communications.  So  much  time  has  been  spent  on  designing,  coding,  and 
debugging  communication  software,  little  has  been  left  for  the  original  research.  Vr;  set 
out  to  provide  an  easy-to-use,  yet  powerful,  set  of  tools  to  aid  in  the  development  of 
multi-computer  projects. 

1.  Approach 

A  communication  protocol  can  be  optimized  for  large  data  transfers,  or  small 
data  transfers,  or  both.  Efforts  to  optimize  for  both  are  both  complex  and  difficult 
[Refs.  2, 31.  File  transfer  protocols  such  as  FTP  in  the  Defense  Advanced  Research 
Project  Agency  (DARPA)  Internet  domain  and  uucp  in  the  UNIX  domain  can  be  used  for 
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large  data  transfers.  Their  overhead1  is  high.  This  overhead  cannot  be  tolerated  in  a 
real-time  problem2.  Our  visual  simulation  efforts  rely  on  small  data  transfers  to 
communicate  among  machines.  These  small  messages  are  typically  commands  and 
changing  status  indicators.  Transferring  the  entire  “world  view”  is  only  a  reasonable  task 
during  initialization  or  reset.  Hence,  we  designed  our  protocols  for  small  messages. 

2.  Design  Criteria 

The  design  criteria  for  developed  protocols  were  simplicity,  ease  of  use, 
portability,  anc’  efficiency.  Rapid  turnover  of  inexperienced  students  at  the  Naval 
Postgraduate  School  makes  simplicity  of  paramount  importance.  Inevitably,  changes 
will  be  required  and  only  a  simple  protocol  is  easily  modified  to  take  advantage  of  new 
capabilities.  Much  the  same  argument,  and  generally  good  software  design  practice, 
make  ease  of  use  only  slightly  less  important  Almost  all  operating  system-level  aspects 
are  hidden  from  the  application.  The  number  of  other  machines  to  be  connected  to,  a  use 
of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  the  only 
concerns  for  the  application  setting  up  a  connection.  The  synchronization,  or  lack 
thereof,  in  communication  between  machines  is  a  design  decision. 

Portability  dictated  our  use  of  TCP/IP,  an  integral  part  of  the  Defense  Data 
Network  (DDN).  Efficient  use  of  processor  power  was  considered  more  important  than 
efficient  use  of  the  network  resources.  The  network  is  shared  by  the  entire  Computer 
Science  Department,  but  is  not  heavily  loaded. 


1  The  cost  of  creating  a  file  and  then  spawning  a  process  to  send  it  is  high.  On  the  receiving  end.  there  is  the  cost 
of  creating  the  file  and  then  reading  it.  Even  a  zero-cost  tile  transfer  protocol  will  require  all  this  overhead. 

2  Large  data  transfers,  in  real-time  systems,  will  not  be  possible  until  100  MByte/Sec  networks  are  commonly 
available. 
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B.  background 

1.  Visual  Simulation 

a.  Vision  and  Information  Presentation 

The  eye  has  the  largest  bandwidth  of  any  human  sensory  organ.  Proper 
use  of  this  capability  is  a  challenge  to  all  scientists.  Static  graphs  are  used  in  most 
disciplines  to  show  the  relationships  between  a  limited  number  of  variables.  These  two- 
dimensional  representations  convey  information  more  readily  to  human  beings  than 
would  a  table  of  the  underlying  numbers.  [Ref.  4:  pp.  8-12] 

Time,  a  common  independent  variable,  is  often  one  dimension  on  a  graph. 
The  other  dimension  is  a  single  dependent  variable.  To  portray  additional  variables  in 
one  presentation  is  a  frequently  occurring  requirement.  Various  techniques  such  as 
multiple  colored  lines,  multiple  icons,  and  perspective  drawing  are  used.  With  each 
technique,  only  a  few  additional  variables  are  added  before  the  graph  becomes 
incomprehensible. 


Pictures,  particularly  those  in  color,  have  a  dense  information  content. 
Unless  blind,  we  live  in  a  world  of  pictures.  Human  beings  can  recognize  many 
differences  between  two  similar  pictures.  One  presentation  portrays  many  different 
variables.  When  a  series  of  pictures  are  presented,  the  tune  variable  is  easily  correlated 
to  the  actual  time  of  presentation.  When  a  series  of  pictures  is  presented  rapidly,  the 
experience  approaches  reality,  partly  explaining  the  success  of  moving  pictures  and 
television. 

Animation  creates  visual  images  with  an  explicit  time  dimension,  in 
addition  to  two  or  three  spatial  dimensions.  Using  actual  time  to  portray  the 
experimental  time  variable  allows  at  least  one  more  dependent  variable  on  the  display. 
Images  can  be  as  simple  as  a  changing  graph,  or  as  complex  as  a  feature-length  cartoon. 


However,  animation  creates  its  effect  with  the  playback  of  prerecorded  scenes  [Ref.  5). 
It  is  not  suitable  for  providing  immediate  feedback  to  a  researcher. 

b.  Definition 

Visual  simulation  is  the  creation,  by  computer,  of  a  realistic,  easily- 
modified,  moving  image  from  the  mathematical  model  of  a  phenomenon.  Realism 
implies  high-resolution,  color  graphics.  Movement  implies  adequate  floating  point 
calculation  capacity  to  recalculate  the  model  and  its  graphical  representation  between 
display  refresh  cycles.  Easy  modification  implies  a  well-designed  computer  application. 

Visual  simulation  allows  a  researcher  to  experiment  easily  with  his 
subject.  Ideally,  we  display  a  realistic  approximation  of  part  of  the  world.  The 
experimenter  then  manipulates  some  part  of  this  visual  simulation  and  receives 
immediate  visual  feedback.  The  rapidly  refreshed  display  is  one  key  to  visual  realism. 
Such  a  display  allows  the  direct  manipulation  of  the  visual  simulation,  making  it  easy 
and  intuitive  to  use  [Ref.  6].  Ease  of  use  allows  the  researcher  to  concentrate  on  the 
research  question,  not  the  display  methodology  or  the  computer  interface. 

c.  Examples 

Recent  visual  simulation  projects  of  the  Graphics  and  Video  Laboratory 
include  speed  control  of  autonomous  vehicles  [Ref.  7],  control  of  autonomous  walking 
machines  [Ref.  8],  rule -based  control  of  autonomous  underwater  vehicles  [Ref.  9], 
interactive  moving  platforms  [Ref.  10]  and  combat  vehicle  control  [Ref.  11].  Each  of 
these  projects  exceeded  the  capacity  of  a  single  workstation.  The  speed  control  and 
interactive  moving  platform  projects,  written  entirely  in  C,  used  two  Silicon  Graphics, 
Inc.  IRIS  workstations,  allowing  multiple  simultaneous  views.  The  other  projects  all 
required  a  rule-based  artificial  intelligence  component,  best  programmed  in  Lisp  for  ease 
of  modification.  Running  the  Lisp  subsystem  on  the  IRIS  workstation  gave  an 
unacceptably  low  refresh  rate  and  correspondingly  poor  realism  [Ref.  12].  Placing  the 


Lisp  subsystem  on  another  machine  improved  the  refresh  rate  of  the  IRIS  workstation 
used  for  the  graphics  display. 


2.  Computer  System  Architecture 

Computer  systems  can  have  a  distributed  or  a  non-distributed  architecture. 
Distributed  architectures  have  only  one  characteristic  in  common,  more  than  one 
processor  used  to  accomplish  the  task.  Beyond  this,  many  different  approaches  have 
been  tried  [Ref.  13].  Identical  processors  give  a  homogeneous  architecture.  Different 
processors  give  a  heterogeneous  architecture.  Either  distributed  architecture  may 
incorporate  shared  memory  or  it  may  not.  The  separate  processors  can  be  closely  or 
loosely  coupled.  Communication  between  processors  can  be  via  shared  memory, 
common  bus,  or  some  form  of  communications  network.  Communication  via  some 
combination  of  the  above,  such  as  a  file  server  on  a  local  area  network,  is  also 
common  [Ref.  3].  In  the  Computer  Science  Department  at  the  Naval  Postgraduate 
School,  a  heterogeneous  mix  of  stand-alone  workstations,  file  server  supported 
workstation  clusters,  and  minicomputers  communicates  via  Ethernet. 

Programming  distributed  architectures  has  inspired  creativity.  The 
fundamental  problems  with  distributed  programming  are  the  communications  between 
processes  and  the  temporal  interaction  of  the  processes.  Communicating  sequential 
processes  [Ref.  14],  distributed  processes  [Ref.  15],  and  remote  procedure  calls 
[Refs.  2, 16]  have  all  been  proposed  as  primitives  to  hide  message  passing  from  the 
programmer.  Remote  procedure  calls  [Refs.  2, 3]  and  communicating  sequential 
processes  [Ref.  17]  have  been  implemented.  However,  even  today,  none  of  these  is 
generally  available  as  a  standard  mechanism  across  varied  architectures.  We  have 
created  simpler  (but  less  general)  communication  routines  for  use  among  heterogeneous, 
distributed,  standalone  computers. 


Complex  projects  can  require  the  resources  of  more  than  one  computer. 
Graphics  portions  are  best  handled  by  the  specialized  hardware  of  a  graphics  workstation, 
such  as  a  Silicon  Graphics,  Inc.  IRIS.  Artificial  intelligence  portions  are  best  handled  by 
a  Lisp  machine,  such  as  a  Symbolics*  or  a  Texas  Instruments  Explorer**.  Database 
requests  can  be  made  to  a  machine  with  appropriate  database  software.  A  general 
purpose  computer,  such  as  the  Digital  Equipment  Corporation  VAX***,  can  be  used  for 
additional  processing  power,  file  storage,  or  other  administrative  support.  Providing  easy 
access  across  such  a  mix  of  heterogeneous  computers  is  a  large  task  [Ref.  3],  The  simple 
mechanism  described  in  this  work  gives  communication  access  between  cooperating 
processes  running  on  diverse  hardware.  It  leaves  temporal  design  to  the  application 
developer,  while  providing  the  tools  for  synchronous  and  asynchronous  interaction. 

3.  Communication 

Communications  between  computers  cooperating  on  a  task  can  be  one-to-one, 
many-to-one,  or  one-to-many.  It  can  be  synchronous  or  asynchronous.  Any,  or  all,  of 
these  can  be  required  for  one  visual  simulation. 

One-to-one,  or  direct  connect,  communications  puts  the  lowest  load  on  the 
network  when  there  are  few  messages  to  be  sent.  A  single  virtual  channel  between  the 
two  processes  is  required.  Each  communication  between  any  two  processes  comprises 
one  message.  All  messages  are  known  to  be  intended  for  the  receiving  process.  These 
messages  can  be  sent  synchronously  or  asynchronously.  Direct  connect  communication 
requires  one  action  by  the  sender  and  one  by  the  receiver.  With  more  processors, 


*  Symbolics  is  a  trademark  of  Symbolics,  Incorporated. 

'*  Explorer  is  a  trademark  of  Texas  Instruments  Incorporated. 

***  VAX  is  a  registered  trademark  of  Digital  Equipment  Corporation 
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potential  virtual  channels  grow  in  number  geometrically.  For  a  fully  connected  network, 
the  virtual  channels  required  can  exceed  capacity.  The  potential  messages  required  also 
grow  geometrically  in  number. 

One-to-many,  or  broadcast,  communications  puts  the  lowest  load  on  the 
sending  process.  A  message  is  sent  to  all  other  processes  that  are  connected  to  it.  It 
requires  one  action  by  the  sender,  and  two  actions  by  each  receiver  (the  reception  and  a 
decision  on  whether  the  message  is  intended  for  that  receiver).  It  also  places  one  to  n 
messages  on  the  network  (depending  on  how  the  network  and  the  broadcast  protocols  are 
designed).  It  is  primarily  used  in  an  asynchronous  mode,  although  synchronous  protocols 
could  be  designed. 

Many-to-one  communications  puts  the  highest  load  on  the  receiving  process.  It 
requires  two  actions  by  the  receiver  on  every  message  that  is  sent  by  any  connected 
process.  It  is  also  a  primarily  asynchronous  method.  The  receiver  portion  of  a  process 
sees  many-to-one  whenever  broadcast  protocols  are  the  only  ones  used  in  a  visual 
simulation. 

C.  Organization 

The  previous  sections  of  this  chapter  provide  background  on  visual  simulation, 
distributed  architectures,  and  communication  paradigms.  Chapter  II  describes  the 
hardware  and  software  environment  in  the  Computer  Science  Department  at  the  Naval 
Postgraduate  School.  The  protocols  developed  are  discussed  in  Chapter  in.  Chapter  IV 
describes  the  implementation  of  the  protocols.  Chapter  V  covers  the  use  of  these 
protocols.  The  performance  of  the  protocols  is  detailed  in  Chapter  VI.  Chapter  VH 
concludes  with  a  discussion  of  limitations,  future  extensions  and  research  topics,  and 
summarizes  the  research  conducted.  Listings  of  the  program  source  code  for  each  of  the 
hardware  systems  are  included  as  Appendices. 


n.  existing  System 


A.  INTRODUCTION 

The  distributed  architecture  available  in  the  Naval  Postgraduate  School  Computer 
Science  Department  Graphics  and  Video  Laboratory  is  Ethernet-connected  workstations 
and  minicomputers.  The  workstations  include  IRIS  2400,  3120,  and  4D  graphics. 
Symbolics  36xx*  and  TI  Explorer  Lisp,  ISI  AI,  and  Sun-3s**.  ^e  minicomputers  include 
VAX  11/785  and  an  ISIV  minicomputer  complex  providing  database  services.  All 
computers,  except  the  Symbolics  and  TI,  use  some  version  of  UNIX***  as  the  primary 
operating  system. 

B.  Hardware 
1.  Network 

Ethernet  connects  all  the  computers  in  our  lab.  There  is  a  backbone  network 
and  subnetworks  for  certain  groups  of  computers.  Currently  there  are  two  subnetworks, 
one  for  the  ISIV  minicomputers  and  one  for  the  ISI  AI  workstations.  Subnetworks  are 
planned  for  the  IRIS  workstations,  the  Sun  Workstations****,  and  the  Symbolics  and  TI 
workstations.  Figure  2.1  illustrates  the  network  configuration. 


*  Symbolics  3600,  Symbolics  3640,  Symbolics  3650,  and  Symbolics  3675  are  trademarks  of  Symbolics.  Inc. 

’*  Sun-3  is  a  trademark  of  Sun  Microsystems,  Inc. 

“*  UNIX  is  a  trademark  of  AT&T  Bell  Laboratories 

****  Sun  Workstation  is  a  registered  trademark  of  Sun  Microsystems,  Inc. 
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All  computers  support  TCP/IP  protocols.  The  Symbolics  Lisp  machines  also 
use  the  CHAOS  protocol  to  provide  file  server  Scr  ces  from  syml  to  the  other  Symbolics 
machines.  This  logical  local  area  network  (LAN)  uses  the  Ethernet  backbone  for  its 
messages.  The  Sun  file  servers  also  support  their  diskless  nodes  over  the  backbone 
Ethernet. 

2.  Workstations 

a.  Silicon  Graphics,  Inc.  IRIS 

Table  2.1  shows  the  IRIS  workstation  configurations.  All  are  connected 
direcdy  to  the  backbone  Ethernet.  The  proprietary  Geometry  Engines  in  each  of  these 
workstations  allows  three  dimensional  color  graphics  displays  to  be  generated  and 
updated  in  real-time.  The  primary  use  of  these  machines  is  for  color  graphics. 

b.  ISI AI 

Table  2.2  shows  the  ISI  AI  workstation  configurations.  Only  ai8  is 
connected  directly  to  the  backbone  Ethernet.  The  other  workstations  are  connected  to  it 
in  a  subnetwork.  These  workstations  are  used  primarily  for  artificial  intelligence 
projects.  The  ai8  machine  provides,  as  well  as  a  gateway  to  the  backbone  Ethernet,  file 
server  support  for  the  other  workstations.  Their  high  resolution  black  on  white  monitors, 
although  bitmapped,  have  rudimentary  graphics  capabilities. 


Table  2. 1  IRIS  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Bit 

Planes 

Floating 

Point 

Accelerator 

Screen 

Resolution 

ast-- 

4D/70G 

8 

380MB 

56 

N/A 

1280x1024 

2400  Turbo 

6 

144MB 

32 

Y 

1024x768 

Mmm 

3120 

4 

144MB 

32 

N 

1024x768 

iris4 

4D/70G 

8 

380MB 

56 

N/A 

1280x1024 

Table  2.2  ISI  AI  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Bit 

Planes 

Screen 

Resolution 

ail 

V8WS 

4 

101MB 

2 

1280x1024 

ai2 

V8WS 

4 

101MB 

2 

1280x1024 

ai3 

V8WS 

4 

101MB 

2 

1280x1024 

ai4 

V8WS 

4 

101MB 

2 

1280x1024 

ai5 

V8WS 

4 

101MB 

2 

1280x1024 

ai6 

V8WS 

4 

101MB 

2 

1280x1024 

ai7 

V8WS 

4 

101MB 

2 

1280x1024 

ai8 

V16WS 

4 

403MB 

2 

1280x1024 

c.  Sun-3/50 

Table  2.3  shows  the  Sun  Workstation  configurations.  All  are  connected 
directly  to  the  backbone  Ethernet.  The  black-on-white  monitors  of  the  Sun  diskless 
workstations  are  primarily  used  for  administrative  tasks  at  this  time. 

d.  Symbolics  36xx 

Table  2.4  shows  the  Symbolics  workstation  configurations.  All  are 
connected  directly  to  the  backbone  Ethernet.  The  Symbolics  workstations  are  used  for  a 


Table  2.3  SUN  WORKSTATION  CONFIGURATIONS 


Nickname 

sunsl 
sunlO 
sunl  1 
sun  12 
sun  13 
sun  14 
sun  15 
sun  16 
sun  17 
sunl8 
sunl9 
suns2 
sun20 
sun21 


Model 
No. 
3/1 80S 
3/50 
3/50 
3/110 
3/110 
3/60 
3/60 
3/60LC 
3/50 
3/50 
3/50 
3/1 80S 
3/60LC 
3/60LC 


Memory 

(MBytes) 

12 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

12 

4 

4 


Disk 

Capacity 

490MB 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

N/A 

490MB 

N/A 

N/A 


Bit 

Planes 

2 

2 

2 

2 

2 

2 

2 

10 

2 

2 

2 

2 

10 

10 


Screen 

Resolution 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 

1280x1024 


R 

I 


■Vi 

i 


Table  2.4  SYMBOLICS  WORKSTATION  CONFIGURATIONS 


Nickname 


Model 

No. 

Memory 

(MBytes) 

1 

Bit 

Planes 

Color 

Screen 

Resolution 

3675 

5 

1GB 

24 

Y 

1280x1024 

3640 

1 

1 

N 

1280x1024 

3640 

1 

180MB 

8 

Y 

1024x1024 

3650 

5 

512MB 

1 

N 

1280x1024 

variety  of  research  projects  involving  artificial  intelligence.  The  syml  machine  provides 
file  server  support  for  the  other  Symbolics  machines  using  the  Chaos  protocol  and  its  one 
GigaByte  (unformatted)  storage  capacity.  The  color-capable  systems  are  used  to  display 
static  information  with  color  providing  an  easier  human  interface, 
e.  Texas  Instruments  Explorer 

Table  2.5  shows  the  Explorer  workstation  configurations.  All  are 
connected  directly  to  the  backbone  Ethernet.  The  TI  Explorers  are  also  used  for  artificial 
intelligence  projects.  They  have  the  least  graphical  capabilities  of  any  of  the 
workstations. 

3.  Digital  Equipment  Corporation  VAX  11/785 

Table  2.6  shows  the  two  DEC*  VAX  11/785  computer  configurations.  Both  are 
connected  directly  to  the  backbone  Ethernet.  Only  the  unixl  machine  was  included  in 
this  project.  The  vmsl  machine  may  not  be  available  in  the  future,  so  the  effort  to 

Table  2.5  EXPLORER  WORKSTATION  CONFIGURATIONS 


Nickname 


Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Bit 

Planes 

Screen 

Resolution 

I 

4 

280MB 

1 

1024x808 

I 

8 

420MB 

1 

1024x808 

I 

8 

420MB 

1 

1024x808 

I 

2 

140MB 

1 

1024x808 

1 


| 


»r 


TO 


Table  2.6  VAX  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Operating 

System 

unixl 

msm 

24 

1395MB 

UNIX 

vmsl 

|pgg 

8 

1442MB 

VMS 

develop  appropriate  code  was  deemed  unnecessary.  The  unixl  machine  is  nps-cs.arpa 
on  MELNET  and  is  the  sole  external  access  point  to  other  machines  connected  locally  via 
Ethernet.  It  supports  the  various  dial-up  lines,  as  well  as  other  administrative  functions. 

4.  IS  IV  minicomputers 

The  computers  in  Table  2.7  make  up  the  ISIV  minicomputer  complex.  Only 
isiv8  is  connected  to  the  backbone  Ethernet.  The  other  machines  are  connected  to  isiv8 
in  an  Ethernet  subnetwork.  The  ISIV  minicomputers  provide  a  high  performance,  multi¬ 
backend  distributed  database.  Any  of  the  high-resolution  black  on  white  monitors  can  be 
used  with  any  of  the  hosts  on  the  subnetwork.  The  character  displays  can  also  be  used  on 
any  of  the  subnetwork  hosts.  The  graphics  capabilities  of  these  machines  are  limited. 


Table  2.7  ISIV  DATABASE  MACHINE  CONFIGURATION 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Bit 

Planes 

Screen 

Resolution 

V24S 

4 

602MB 

N/A 

80x24char 

■III  ~ 

V24WS 

4 

500MB 

2 

1280x1024 

MSI  ■ .. . 

V24WS 

4 

602MB 

2 

1280x1024 

V24WS 

4 

500MB 

2 

1280x1024 

isiv5 

V24S 

4 

602MB 

N/A 

80x24char 

isiv6 

V24S 

4 

602MB 

N/A 

80x24char 

isiv7 

V24WS 

4 

602MB 

2 

1280x1024 

isiv8 

V24WS 

4 

459MB 

2 

1280x1024 

isiv9 

V24S 

4 

602MB 

N/A 

80x24char 

C.  SOFTWARE 


1.  UNIX  Machines 

Two  version  of  UNIX  are  commonly  used.  The  machines  purporting  to  use 
System  V*,  also  incorporate  characteristics  of  4.2BSD  and  4.3BSD.  The  relevant 
incorporation  is  the  Berkeley  socket  mechanism. 

a.  4.3BSD 

A  "pure"  4.3BSD  system  (4.3  BSD  UNIX  #11)  exists  only  on  unixl.  The 
IS IV  minicomputers  use  4.2  BSD  UNIX  Release  3.07,  with  a  multi-backend  database 
system  installed  [Refs.  18-20].  The  ISI  AI  workstations  use  IS68K  4.3  BSD  UNIX:  4.0D 

#2. 

b.  System  V 

The  IRIS  4D  systems  use  UNIX  System  V-based  version  4D  1-2.2.  The 
DRIS  2400  and  3120  systems  use  UNIX  System  V-based  version  GL2-W3.6.  Both  have 
extensive  4.3BSD  extensions.  The  Sun-3  uses  an  almost  System  V  version  of  4.2BSD 
UNIX.  The  currently  installed  release  is  3.4. 

2.  Lisp  Machines 
a.  Genera 

The  Symbolics  Lisp  Machines  first  used  Genera  6.0  software.  All 
machines  are  now  on  Genera  7.1. 
b  Explorer 

The  TI  Explorer  lisp  machine  first  used  Explorer  version  1.0.2  software. 
All  machines  are  now  on  version  3.4  except  e.xpl ,  which  is  still  on  version  3.2. 


’  UNIX  System  V  is  a  trademark  of  AT&T  Bell  Laboratories 


D.  Summary 


The  configuration  described  above  is  constantly  changing.  Additional  machines  are 
acquired.  Older  machines  receive  hardware  upgrades.  The  network  is  reconfigured. 
Software  releases  are  updated  (especially  4.2BSD  UNIX  to  4.3BSD  UNIX).  The 
fundamental  needs  for  distributed  computation  in  this  heterogeneous  environment 


m.  Protocols 


A.  INTRODUCTION 

Our  visual  simulation  efforts  rely  on  small  data  transfers  to  communicate  among 
machines.  These  small  messages  arc  typically  commands  and  changing  status  indicators. 
Hence,  we  optimized  our  protocols  for  small  messages.  Overhead  to  optimally  encode 
and  decode  packets  was  deemed  inappropriate.  The  design  criteria  for  developed 
protocols  were  simplicity,  ease  of  use,  portability,  and  efficiency. 

B.  DIRECT  CONNECTION 

The  client/server  paradigm  is  used  for  direct  connection.  The  client  requests 
services  from  the  server,  so  establishing  communications  is  asymmetrical.  Once 
communications  are  established,  however,  the  protocol  used  is  completely  symmetrical. 
[Ref.  21:  p.  17] 

1.  High-Level  Protocol 

The  variety  of  data  types  supported  is  limited  (see  Table  3.1).  Each  message 
contains  exactly  one  instance  of  one  type  of  data.  All  integer  or  float  data  is  converted  to 
an  ASCII  character  string  before  it  is  sent.  It  is  converted  back  to  the  proper  type  after 


Table  3.1  DATA  TYPES  SUPPORTED 


reception.  While  the  conversion  is  unnecessary  when  communicating  between  similar 
architectures,  it  greatly  simplifies  the  task  of  communicating  between  fundamentally 
different  architectures.  Knowledge  of  the  other  machine’s  architecture  is  not  required. 
The  inherent  portability  of  this  solution  outweighs  the  processing  cost. 

A  message  is  created  with  three  fields.  The  type  field  is  a  one-character  field. 
It  contains  the  appropriate  code  from  Table  3.1.  The  length  field  is  a  four-character  field. 
It  contains  an  ASCII  string  from  0001  to  9999.  This  string  gives  the  length  of  the  data 
field.  The  data  field  is  a  variable  length  field  containing  the  ASCII  representation  of  the 
data  element.  Figure  3.1  illustrates  these  fields. 

While  C  programmers  are  continuously  concerned  with  data  types,  Lisp 
programmers  are  not.  The  Lisp  routines  support  arrays  of  characters,  single  integers,  and 
single  floating  point  numbers.  Each  of  these  is  an  object.  Objects,  not  types  (as  implied 
in  Table  3.1),  are  received  and  sent  by  lisp  applications.  The  underlying  protocol  is  the 
same,  the  application  interface  is  different3. 


Position 


Figure  3.1  Message  Format 


3  Giapter  5  discusses  applications’  use. 


Full-duplex  stream  sockets  are  used  to  provide  sequenced,  reliable  connection 
between  machines.  The  sockets  are  created  in  the  DARPA  Internet4  domain.  The 
Internet  pseudo-protocol  is  used  [Ref.  22].  No  out-of-band  capability  was  included.  We 
could  not  envision  a  use  for  it,  since  our  protocol  is  inherently  asynchronous.  If  a  strictly 
synchronous  protocol  was  used,  out-of-band  transmission  might  be  necessary  to  interrupt 
for  an  urgent  message.  In  an  asynchronous  protocol,  however,  encoding  the  next 
message  gives  the  same  effect.  Processing  overhead  for  encoding  is  no  greater  than  for 
continuous  monitoring  for  an  out-of-band  message.  With  only  a  small  volume  of  data 
transfers  expected,  no  urgent  message  waits  very  long. 

Two  ports,  each  with  its  own  stream  socket,  are  used  for  each  channel  between 
machines.  Although  full-duplex,  the  stream  sockets  are  used  in  a  simplex  mode.  The 
separate  sockets  are  used  because  two  processes  cannot  be  bound  to  the  same  socket  at 
the  same  time.  Two  separate  UNIX  processes  then  monitor  the  independent  send  and 
receive  sockets.  Blocking  sockets  are  used,  avoiding  processing  overhead  for  busy¬ 
waiting.  While  non-blocking  sockets  are  available  in  4.3BSD  [Ref.  21:  p.  25],  they  were 
not  explicitly  available  in  4.2BSD  [Ref.  22].  Operating  systems  might  include  4.2BSD 
sockets  rather  than  4.3BSD  versions  and  so  the  blocking  socket  mechanism  was  deemed 
more  portable.  Both  TCP/IP  and  the  C  routines  provide  buffering. 

On  the  TI  Explorer,  sockets  were  also  blocking5.  Direct  access  was  made  to 
the  TCP  methods  provided.  Lisp  streams  are  used  for  the  Symbolics  lisp  routines.  The 

4  This  is  the  underlying  mechanism  of  the  Defense  Data  Network  (DDN)  and  was  chosen  for  its  wide  availability 
and  applicability  to  Department  of  Defense  problems. 

5  Version  1.0  of  the  Explorer  TCP/IP  software  uses  blocking  sockets.  Version  2.0  uses  non-blocking  sockets. 
There  has  been  no  update  of  this  system’s  TI  Explorer  lisp  routines  to  version  2.0. 


l'U.<>i<4rf:<iL< 


UUlI 


lisp  stream  mechanism  isolates  the  code  from  the  issues  revolving  around  blocking 
versus  non-blocking  sockets. 


C.  BROADCAST 

A  broadcast  message  is  sent  to  all  machines  on  a  local  Ethernet.  Those  machines 
that  are  waiting  for  some  broadcast  message  will  probably6  receive  it.  If  a  machine  on  a 
subnetwork  is  to  get  a  broadcast  message,  an  application  must  run  on  the  gateway 
machine  that  will  rebroadcast  on  the  subnetwork  any  messages  received  on  the  backbone 
Ethernet.  Machines  not  expecting  a  broadcast  message  must  nevertheless  process  it  and 
reject  it  as  inappropriate.  The  extra  load  on  all  machines  connected  to  the  Ethernet 
restricts  broadcasting  to  infrequent  occurences  until  most  of  the  machines  used  in 
simulations7  are  on  a  private  subnetwork. 

1.  High-Level  Protocol 

We  expect  users  of  the  broadcast  protocol  to  mix  its  use  with  the  use  of  direct 
connections.  The  same  data  types  and  messages  are  supported  (see  Table  3.1). 

2.  Supporting  Protocols 

Full-duplex  datagram  sockets  are  used  to  provide  connectionless  broadcast 
capability.  The  sockets  are  created  in  the  DARPA  Internet  domain.  As  with  our  use  of 
stream  sockets  for  the  direct  connection  protocol,  we  use  these  full-duplex  datagram 
sockets  in  a  simplex  mode.  We  use  a  sending  socket  for  one-way  sending  of  a  broadcast 
message  to  all  other  machines  on  a  single  network  or  subnetwork.  We  use  a  receiving 
socket  for  one-way  receiving  from  a  specific  broadcasting  machine  on  the  network  or 


6  Unlike  the  direct  connect  protocol,  the  broadcast  protocol  does  NOT  guarantee  reception.  Trying  to  provide 
such  a  guarantee  requires  a  feedback  machanism  so  that  the  sender  knows  that  the  machines  expected  to  receive  the 
broadcast  did  so.  This  is  difficult  without  resorting  to  a  direct  connection  or  flooding  the  network  with  messages. 

7  Tile  IRIS  machines  and  the  Lisp  machines  are  the  ones  principally  used  for  visual  simulation. 
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subnetwork.  Direct  connection,  with  its  use  of  guaranteed  reliable  stream  sockets ,  is 
used  for  any  other  communication,  including  return  messages.  [Ref.  21:  pp.  32-34] 

As  in  the  direct  connection  protocol,  independent  UNIX  processes  are  bound  to 
the  sockets.  Since  broadcasting  is  a  one-way  activity,  a  sender  or  receiver  only  spawns 
one8  UNIX  process. 

D.  Summary 

By  building  our  high-level  protocols  on  top  of  DARPA  TCP/IP  standards,  we  provide 
the  highest  degree  of  portability  possible  today.  By  using  full-duplex  stream  sockets  and 
datagram  sockets  in  a  simplex  mode,  we  do  not  make  full  utilization  of  a  socket’s 
capabilities.  However,  this  concern  is  outweighed  by  the  increased  simplicity  and 
resultant  maintainability  of  the  code.  The  use  of  ASCII  character  strings  for  the  messages 
is  simple  and  makes  interconnection  with  diverse  architectures  straightforward. 


*  If  broadcasting  were  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  n  processes. 
If  direct  connection  was  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  2n-2  processes. 
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IV.  IMPLEMENTATIONS 


A.  Introduction 


The  first  connection  was  between  the  IRIS  2400-Turbo  and  TI  Explorer.  Then  the 
Symbolics  Lisp  machines  were  included.  These  routines  have  had  extensive  use 
[Refs.  8,9, 11].  The  IRIS  functions  were  updated  for  the  IRIS  4D,  coincidentally 
providing  Mex  support  on  the  older  IRIS  machines.  Broadcast  capability  was  added  for 
UNIX-based  machines.  A  port  to  4.3BSD  UNIX  (application  calls  unchanged)  was  begun. 


B.  System  V  UNIX 

All  our  System  V  UNIX-based  systems  include  the  socket  mechanism  first 
introduced  by  4.2BSD.  Sockets  are  a  key  aspect  of  all  implementations.  We  expect  they 
will  become  part  of  System  V  or  its  successors  [Ref.  23].  The  System  V-unique 
semaphore  and  shared  memory  interprocess  communication  (IPC)  capabilities  are  also 


1.  Silicon  Graphics.  Inc.  IRIS  2400 
a.  Sockets 

The  socket  was  introduced  in  4.2BSD  as  the  preferred  metaphor  for  IPC.  It 
was  easy  and  efficient  to  implement  and  the  select  mechanism  could  be  used  to 
implement  remote  procedure  calls,  if  desired  [Ref.  23].  System  V  had  no  comparable 
mechanism  until  version  3  was  released  with  streams.  The  BSD  sockets  were  included 
by  many  vendors,  Silicon  Graphics,  Inc.  included9.  While  the  use  of  sockets  could  be 


q  The  System  V  version  available  on  the  IRIS  machines,  at  the  start  of  the  project,  was  version  2  and  so  streams 
were  not  considered. 
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replaced  with  streams,  device  drivers  would  have  to  be  written.  The  advantage  of 
streams  is  the  ability  to  filter  them  between  streamhead  and  the  actual  device  driver. 
These  filters,  however,  reside  in  the  kernel’s  address  space  and  have  the  kernel’s 
permissions  [Ref.  24].  In  our  environment,  the  potential  performance  increase  is  not  as 
important  as  the  requirement  for  simplicity. 

The  system  call  for  socket  creation  is  socket.  The  system  calls  supporting 
socket  configuration  are  setsockopt,  bind ,  connect,  and  accept 10  [Ref.  22].  To  simplify 
their  use,  these  are  all  repackaged  into  four  high  level  routines:  connect  server  and 
connect  client  for  direct  connection,  start  broadcast  and  broadcast  receive  for 
broadcast.  These  routines  are  encapsulated  in  netV.c.  netV.c  can  be  separately  linked 
with  any  application  that  needs  to  make  a  server/client  connection  using  stream  sockets 
or  a  broadcasting  connection  using  datagram  sockets.  Table  4.1  describes  the  four 
routines. 

Using  the  socket  number11,  a  process  can  transmit  data  through  the  socket. 
In  our  system,  sockets  for  inter-computer  communication  are  created  and  used  by  the 
send  and  receive  processes  exclusively.  The  file  netV.c  is  not  linked  with  the  application 
at  all. 


10  The  accept  system  call  is  only  relevant  to  stream  sockets.  The  setsockopt,  bind,  and  connect  system  calls  are 
used  with  both  stream  sockets  and  datagram  sockets. 

"  In  the  direct  connect  protocol,  the  server  process  reads  from  and  writes  to  a  remote  socket  number.  The  client 
process  reads  from  and  writes  to  its  local  socket  number.  The  reason  for  this  is  that  a  server  could  be  connected  to  dif¬ 
ferent  clients  (although  not  in  our  implementation)  at  different  times.  The  client,  meanwhile,  is  only  going  to  connect 
to  the  one  server.  In  the  Internet  domain,  all  necessary  routing  information,  for  either  server  or  client,  is  contained  in  a 
sockaddrjn  stnicture  and  is  accessed  (transparently)  via  the  socket  number. 

In  the  broadcast  protocol,  both  the  broadcaster  and  receiver)  s)  use  their  local  socket  number  because  they  are 
using  connectionless  datagram  sockets.  The  routing  information  is  also  contained  in  a  sockaddr  in  structure. 
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Table  4. 1  SOCKET  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

connect_server 

Creates  socket.  Binds  that 
socket  to  remote  client  ad¬ 
dress  and  port.  Waits  to  ac¬ 
cept  the  remote  client  con¬ 
nection.  Returns  the  socket 
number  for  the  remote  client. 

int  connect_serverf  remote_client_name,  port_number  ) 
char  remote_client_name[]; 
int  port_number; 

remote_socket  =  connect_server(  remote_client_name, 

port_number ) 

connect_client 

Creates  socket.  Binds  that 
socket  to  remote  server  ad¬ 
dress  and  port.  Connects 
with  remote  server.  Returns 
the  local  socket  number. 

int  connect_client(  remote_server_name,  port_number  ) 
char  remote_server_nameQ; 
int  port_number, 

local_socket  =  connect_ciient(  remote_server_name, 

port_number  > 

start_broadcast 

Creates  socket.  Sets  it  to 
broadcast  mode.  Binds  it  to 
local  address  and  specified 
local  port.  Returns  the  local 
socket  number. 

int  start_broadcast(  port_number ) 
int  port_number, 

local_socket  =  start_broadcast(  port_number  ) 

broadcastjreceive 

Creates  socket.  Binds  it  to 
local  address  and  specified 
port.  Adds  broadcaster  ad¬ 
dress  and  port.  Returns  the 
local  socket  number. 

int  broadcast_receive(  broadcaster_name,  broadcaster_port  ) 
char  broadcaster_name[]; 
int  broadcaster_poit; 

local  socket  =  broadcast_receive(  broadcaster_name, 

broadcaster_port ) 

b.  Semaphores 

The  semaphore  mechanism  was  chosen  as  the  least  expensive,  in  both 
space  and  time,  for  communication  between  processes.  Signals  could  have  been  used, 
but  implementation  would  have  been  more  complex  and  less  reliable.  Signal-based 
communication  functions  would  also  have  been  more  difficult  for  the  application 
programmer  to  use  [Ref.  25:  p.  10].  There  are  two  semaphore  ids  maintained  for  each 
connection12.  One  is  used  to  communicate  with  the  send  process;  one  is  used  to 
communicate  with  the  receive  process.  The  two  semaphores  are  both  used  to  signal  their 
process  when  it  is  safe  to  proceed.  A  send  process  is  permitted  to  proceed  only  after  the 


12  Two  semaphore  ids  are  required  for  direct  connect  protocol  connections  since  bo’’’  a  send  and  a  receive  pro¬ 
cess  are  spawned.  Two  semaphore  ids  are  still  created  for  broadcast  protocol  connections,  even  though  only  one  pro¬ 
cess  is  spawned. 


23 


application  has  requested  a  write  action13  on  the  channel.  A  receive  process  is  permitted 
to  proceed  only  after  the  application  has  read  all  data  from  the  shared  memory  buffer. 
Neither  the  send  nor  the  receive  process  is  executing  more  than  absolutely  necessary, 
assuring  maximum  availability  of  the  local  processor  to  the  application. 

The  system  calls  supporting  semaphores  are  semget,  semop,  and  semctl. 
To  simplify  their  use,  they  are  repackaged  into  three  high  level  routines:  semtran,  P,  and 
V  [Ref.  25:  pp.  188-190].  These  routines  (and  a  support  routine  semcall )  are 
encapsulated  in  semaphores.  It  can  be  separately  linked  with  any  application  that  needs 
semaphores.  Table  4.2  describes  the  three  routines, 
c.  Shared  Memory 

A  cost  barrier  to  BPC  in  UNIX  is  the  cost  of  copying  data  from  one  process 
to  the  kernel  and  then  from  the  kernel  to  another  process.  Using  a  shared  memory 
segment,  as  a  buffer,  minimizes  this  overhead.  To  further  reduce  overhead  from  system 
calls,  only  a  single  segment  is  created.  An  application  accesses  the  entire  segment,  while 
a  send  or  receive  process  accesses  only  its  preassigned  section.  Figure  4.1  displays  the 
layout.  The  message  area  of  each  section  is  used  for  several  purposes.  It  is  formatted  as 


Table  4.2  SEMAPHORE  SUPPORT  FUNCTIONS 


Function 


Description 


Creates  a  semaphore  associ-  ^  semtran(  key  ) 
Semtran  ated  with  a  key.  Returns  a  int  key; 

semaphore  id.  sid  =  semtranf  ke\ 


Acquire  semaphore 


Release  semaphore 


sid  =  semtran(  key  ); 
void  P(  sid ) 

int  sid; _ 

void  V(  sid ) 
int  sid; 


13  The  data  must  also  be  valid  in  the  shared  memory  buffer.  All  this  is  transparent  to  the  application,  which  only 
issues  a  write  command. 


VJVV->V-V- 


„  %  %  .v  \  v  v 

J*  A  ^  , 


/.  ,v  /  -* 


where  n  =  LARGESTREAD  from  shared. h 

Figure  4.1  Shared  Memory  Segment  Data  Assignment 


a  long  (4-byte)  integer.  Table  4.3  describes  the  meaning  of  three-state  values  placed  in 
this  area. 


Table  4.3  SHARED  MEMORY  MESSAGES 


Value 


Meaning 

to 

send 

Meaning 

to 

receive 

Meaning 

to 

Application 

Data  of  length  given  is 

Application  has  not 

send:  Data  in  shared  memory 
has  not  yet  been  sent  to  other 
machine. 

in  shared  memory, 
ready  to  be  sent. 

finished  reading  data 
from  shared  memory. 

receive:  Valid  data  of  length 
given  is  in  shared  memory, 
ready  to  be  read. 

Nothing  ready  to  be 

Application  has  read 
data  from  shared 

memory.  Message 

send:  Previous  message  has 
been  sent.  Ready  to  send 
next  message. 

sent. 

from  other  machine  can 
be  read,  up  to  LAR¬ 
GESTREAD  bytes. 

receive:  No  valid  data  in 
shared  memory. 

Signal  to  terminate. 

Signal  to  terminate. 

N/A 

vs 


W! 


The  system  calls  supporting  shared  memory  are  shmget,  shmat,  shmdt ,  and 
shmctl  [Ref.  25:  pp.  192-198J.  To  simplify  their  use,  they  are  repackaged  into  four  high 
level  routines:  sharedsegment ,  dynamicsharedsegment,  detachsliaredsegment,  and 
deletesharedsegment.  These  routines  (and  a  support  routine  attach_within_datasegment) 
are  encapsulated  in  shareseg.c.  It  can  be  separately  linked  with  any  application  that 
needs  shared  memory.  Table  4.4  describes  the  four  routines. 

The  implementation  of  shared  memory  on  the  IRIS  2400  and  IRIS  3120 
was  a  surprise.  A  basic  UNIX  memory  allocation  scheme  is  shown  in  Figure  4.2.  Each 
process  has  its  own  text,  data,  and  stack  sections.  Neither  the  relative  locations  of  these 
sections  nor  the  direction  of  growth  for  stack  and  data  sections  is  specified  for  UNIX. 
The  shared  memory  segments  are  logically  part  of  the  data  section  [Ref.  26:  p.  151]. 


Table  4.4  SHARED  MEMORY  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

sharedsegment 

Creates  (if  not  already  in  ex¬ 
istence)  a  shared  memory 
segment  associated  with  a 
key.  Attaches  application  to 
that  shared  memory  segment. 
Returns  a  shared  memory 
segment  address  and  id. 
Does  not  permit  subsequent 
dynamic  memory  allocation. 

char  ‘sharedsegment!  key,  nbytes,  shmid  ) 
long  key; 
long  nbytes; 
int  *shmid; 

segment  =  sharedsegment(  key,  nbytes,  shmid  ) 

dynamicsharedsegment 

Creates  (if  not  already  in  ex¬ 
istence)  a  shared  memory 
segment  associated  with  a 
key.  Attaches  application  to 
that  shared  memory  segment. 
Returns  a  shored  memory 
segment  address  and  id.  Per¬ 
mits  subsequent  dynamic 
memory  allocation. 

char  *dynamicsharedsegment(  nummachines, 
key,  nbytes,  shmid,  free  space  ) 
int  nummachines; 
long  key; 
long  nbytes; 

int  ‘shmid; 
int  freespace: 

segment  =  dynaniicsharedsegment(  num- 

machines,  key,  nbytes.  shmid,  freespace  ) 

detachsharedsegment 

Detach  shared  memory  seg¬ 
ment  from  application 

void  detachsharedsegment!  segment  ) 
char  ‘segment; 

deletesharedsegment 

Delete  shared  memory  seg¬ 
ment 

void  deletesharedsegment!  segment,  shmid  ) 
char  ‘segment: 

int  shmid: 
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Figure  4.3  IRIS  2400  Default  Shared  Memory  Attachment 


relationship.  While  no  dynamic  memory  calls15  are  made,  the  default  arrangement  works 
fine.  But  when  dynamic  memory  allocation — linked  lists  and  makeobjO  calls  are 
examples — is  needed,  the  technique  fails. 

To  allow  dynamic  memory  allocation,  the  shared  memory  segment  must 
be  attached  at  an  address  beyond  the  greatest  ever  required  for  regular  data.  Dynamic 
allocation  can  then  occur  without  reaching  the  shared  memory  segment.  Attaching  at  an 
unknown  address  both  within  the  data  section  and  sufficiently  beyond  existing  data  to 
permit  dynamic  data  section  growth,  can  be  done  at  least  two  ways.  First,  'he  data 
section  can  be  expanded  until  it  is  as  large  as  possible,  then  the  shared  memory  segment 


15  Dynamic  memory  allocation  is  made  with  system  call  brk  or  alternate  sbrk.  Library  functions  mail  or,  rcalloc, 
and  callot  use  brk  and  so  also  do  dynamic  memory  allocation. 


can  be  attached  at  a  valid  location  just  inside  this  maximum  value.  While  minimizing 
application  programmer  effort,  this  technique  requires  many  system  calls  to  grow  the 
data  section.  It  also  has  the  fatal  flaw  of  limiting  the  stack  section,  if  the  stack  section 
and  data  section  grow  into  the  same  unallocated  memory.  Second,  the  application  can  be 
required  to  prespecify  the  maximum  amount  of  dynamic  memory  allocation  it  might  use. 

The  solution  adopted  is  adding  a  freespace  parameter  to  the 
sharedsegment  function;  and  renaming  it  the  dynamicsharedsegment  function.  The 
sharedsegment  function  was  retained  for  backward  compatibility.  The  freespace 
parameter  gives  the  caller  the  ability  to  specify  the  maximum  additional  memory 
required  for  the  application.  A  request  for  this  additional  space  is  made  before  the  shared 
memory  segment  is  attached.  After  acquiring  (and  freeing)  the  additional  space,  the  next 
available  address  is  determined  and  the  shared  memory  segment  is  attached  to  the  next 
valid  address.  We  have  now  established  the  shared  memory  segment  beyond  the 
specified  growth  of  the  application’s  data. 

When  multiple  machines  are  connected  together,  there  must  be  a  separate 
shared  memory  buffer  for  each  channel.  There  is  no  way  to  connect  a  second  shared 
memory  segment.  The  solution  adopted  is  adding  a  nummachi nes  parameter  to  the 
dynamicsharedsegment  function.  The  nummachines  parameter  requires  the  application 
developer  to  specify,  in  advance,  the  maximum  number  of  channels  that  can  be  created  in 
the  application.  The  first  dynamicsharedsegment  call  establishes  a  shared  memory 
segment  big  enough  for  nummachines  maximum  requested  channels.  Subsequent 
dynamicsharedsegment  calls  return  the  same  shared  memory  id  as  the  first;  but  return  a 
different  address  within  the  segment.  Since  the  application  does  not  directly  access  these 
functions,  there  were  no  problems  caused  by  this  parameter  list  change. 


The  shared  memory  functions  are  isolated  from  the  application  by  the 
machinepath,  dynamicmachinepath ,  dynamicmachinepaths ,  and  deletemachinepath 
functions16.  For  the  direct  connect  protocol,  each  machinepath,  dynamicmachinepath,  or 
dynamicmachinepaths  call  spawns  both  a  send  and  a  receive  process.  For  the  broadcast 
protocol,  these  calls  spawn  only  a  send  process  (for  the  broadcaster)  or  a  receive  process 
(for  the  receiver).  In  all  cases,  the  spawned  processes  issue  a  sharedsegment  call  to 
attach  to  the  shared  segment  earlier  created  by  the  spawning  function.  A  command  line 
parameter  is  passed  providing  the  offset  into  the  shared  memory  segment  that  the 
spawned  process  is  to  use.  Figure  4.4  illustrates  a  system  with  three  machines  and  two 
channels. 

d.  Buffering 

(1)  Direct  Connect.  When  a  receive  process  is  quiescent,  waiting  for 
the  application  to  read  from  the  shared  memory  buffer,  anything  sent  to  it  is  buffered  by 
TCP/DP.  The  buffering  provides  the  reliable  delivery  promised  by  a  stream  socket.  The 
next  read  command  will  deliver  up  to  LARGESTREAD  bytes  into  the  receive  data  area  of 
the  shared  memory  buffer.  Since  the  messages  are  variable  length,  there  cannot  be  a 
guarantee  that  only  one  message  was  read17.  Multiple  messages  might  be  in  the  shared 
memory  buffer.  A  partial  message  might  be  in  the  last  bytes. 

The  shared  memory  buffer  management  is  handled  by  the  various 
read  functions  provided.  Each  read,  requested  by  the  application,  is  satisfied  from  the 

16  See  Chapter  5,  Sections  A.l.b(  1)  and  A.  l.b(3)  for  more  information  on  these  functions. 

17  The  idea  to  pad  all  messages  to  some  arbitrary  size  was  considered  and  rejected.  Whatever  size  was  chosen 
would  always  be  too  small  for  some  character  arTay.  If  the  maximum  Ethernet  packet  size  was  chosen,  an  unnecessary 
network  dependence  would  be  introduced.  The  cost  of  application  buffer  management  is  considered  acceptable,  espe¬ 
cially  since  it  is  incurred  only  on  reads. 

"  See  Chapter  5,  Section  A.  l.b(2)  for  more  information  on  these  functions 
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shared  memory  buffer.  Remaining  valid  data  is  shifted  into  the  low  order  positions  of  the 
data  area.  The  count  of  valid  bytes,  held  in  the  message  area,  is  decremented.  The 
shared  memory  buffer  now  appears  as  it  would  have,  if  it  had  only  received  the 
remaining  data  and  not  the  first  message  at  all.  As  long  as  only  entire  messages  are 
received  (one  or  more  at  a  time),  this  works  well.  When  the  TCP/IP  buffer  has  more  data 
than  the  data  area  can  take  at  one  time,  however,  the  receive  process  deposits 
LARGESTREAD  bytes  in  the  shared  memory  data  area.  It  is  highly  unlikely  that  this  will 
be  on  a  message  boundary. 

A  socket  read  overwrites  all  data  in  the  data  area.  A  partial  data 
reception  must  be  stored  and  concatenated  with  bytes  from  the  next  socket  read  to  get  a 
complete  message.  The  protocol  area  was  introduced  to  retain  the  protocol 
information19  required  to  decipher  the  variable  length  messages.  The  count  of  already 
received  bytes  of  a  message  is  held  here  between  socket  reads.  A  message’s  protocol 
information  is  stored  here,  too.  Protocol  information  is  built  up  until  complete  (covering 
the  possibility  that  the  break  is  in  the  protocol  information  itself).  It  is  then  maintained 
until  the  entire  message  is  received  and  read  by  the  application.  The  buffering  works 
with  data  areas  as  small  as  four  bytes20. 

(2)  Broadcast.  The  datagram  socket  used  by  the  broadcast  protocol 
preserves  message  boundaries.  Each  recvfrom  call  to  a  socket  returns  only  one  message. 
This  message  must  be  no  longer  than  LARGESTREAD  bytes.  The  shared  memory  buffer 
management  routines  are  not  needed. 

9  See  Chapter  3,  Section  B.  1  for  a  description  of  the  protocol 

20  LARGESTREAD  must  be  specified  in  multiples  of  four  bytes.  The  smallest  possible  data  area  is  therefore 
four  bytes. 
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TCP/IP  keeps  unread  messages  on  a  queue.  This  queue  may  not  be  in 
sending  sequence.  If  the  queue  buffer  becomes  full,  subsequent  messages  are  lost 
[Ref.  21:  p.  8-8].  The  sending  buffer  can  easily  be  filled  if  many  messages  are  broadcast 
in  a  short  period  of  time.  Each  broadcast  message  must  be  processed  by  every  host  on 
the  Ethernet.  Only  then  can  the  next  be  sent.  No  access  for  manipulation  of  the  TCP/IP 
sending  buffer  is  provided  because  its  size  is  normally  specified  during  system  generation 
and  is  not  easily  manipulated  by  an  application  program. 

2.  Silicon  Graphics.  Inc.  IRIS  3120 

There  are  no  required  changes  to  the  IRIS  2400-Turbo  code.  The  Makefile 
must  be  changed  to  remove  the  -Zf  compile  flag,  since  there  is  no  floating  point 
accelerator  board  in  this  machine. 

3.  Silicon  Graphics.  Inc.  IRIS  4D 

The  IRIS  4D  required  programming  changes  only  to  the  shared  memory 
module,  shareseg.c.  The  path  name  for  user  directories  is  also  different.  Changes  were 
necessary  to  the  Makefile  because  the  lusrl include  directory  structure  changed. 

The  IRIS  4D  is  based  on  the  MIPS  RISC  architecture.  The  UNIX 
implementation  was  done  differently  than  that  for  the  Motorola  68020.  Shared  memory 
segments  are  not  attached  to  addresses  within  the  data  section,  as  illustrated  in  Figure 
4.5.  They  are  attached  at  a  much  higher  address,  yet  accessing  them  does  not  result  in  a 
segmentation  violation.  This  is  a  more  robust  technique  that  obviates  any  manipulation 
of  attachment  addresses.  Multiple  shared  memory  segments  are  easily  attached,  using 
default  system  calls.  The  sharedsegment  call  suffices,  even  when  dynamic  memory 
allocation  is  needed.  To  maintain  backward  compatibility  for  application  code, 
dynamicsharedsegment  calls  sharedsegment,  ignoring  the  freespace  parameter,  when 
compiled  on  an  IRIS  4D,  and  calls  attach  jvithinjiatasegment  when  compiled  on  an 
older  IRIS  machine. 
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Shared  kencrv  Sennet  t 
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Figure  4.5  IRIS  4D  Default  Shared  Memory  Attachment 


C.  4.3BSD  UNIX 

The  netV.c  file  functions  properly  on  a  4.3BSD  machine  that  is  connected  to  only 
one  network.  The  start -broadcast  function  does  not  properly  handle  multiple  networks. 
The  other  functions  work  correctly,  even  when  the  machine  is  connected  to  multiple 
networks. 

All  other  functions  depend  upon  semaphores  and  shared  memory  for 
communication  between  the  spawned  processes  and  the  main  application.  Stream 
sockets"  could  be  used  to  provide  the  IPC  between  these  processes  under  4.3BSD.  The 


21  Unidirectional  stream  sockets  are  equivalent  to  pipes. 
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three  channels22  used  will  have  to  be  multiplexed  into  one,  but  the  implementation  is 
otherwise  straightforward. 

D.  lisp  Machines 

The  communication  code  is  a  flavor  to  be  mixed  with  the  application  [Ref.  11].  The 
Explorer  software  is  syntactically  equivalent  to  Genera  6  on  the  Symbolics.  With  a 
simple  change  in  the  sequence  of  method  and  flavor  names,  the  Genera  7  code  runs  on 
the  TI  Explorer.  The  older  flavor,  originally  developed  for  the  Explorer,  is  also  presented 
to  illustrate  working  directly  with  TCP/IP  instead  of  using  a  stream. 

1.  Texas  Instruments  Explorer  I 

This  older  flavor  works  with  Release  1.0  of  the  Explorer  TCP/IP  software.  It 
will  not  work  with  Release  2.0  as  the  implementation  was  changed  from  blocking  to 
non-blocking  [Ref.  27]. 

Messages  to  the  flavors  in  the  ip  package  are  made  together  with  messages  to 
the  tcp  flavors.  Network-independent  addressing  is  not  used.  Table  4.5  describes  the 
addressing  schemes  possible  [Ref.  28:  pp.  4-2 — 4-3].  Class  C  addressing  is  used  by  the 
Computer  Science  Department.  Figure  4.6  shows  the  simple  encapsulation  of  the 
addresses  for  irisl ,  iris2,  and  iris3.  Extension  to  include  other  machines  is  easy. 

Table  4.5  INTERNET  ADDRESSING  CLASSES 


Class 

No. 

Networks 

No. 

Hosts 

A 

128 

16,777,216 

B 

16,384 

65,536 

C 

2,097,152 

256 

22  These  are  the  semaphore,  the  message  areas  of  the  shared  memory  buffer,  and  the  data  areas  of  the  shared 
memory  buffer.  The  first  is  unidirectional  from  application  to  spawned  process.  The  second  is  bidirectional  and  three 
state  (see  Table  4.3). 
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(defvar  *  i  r  i sl-address*  3221866502) 
(defvar  * i r i s2 - addre $ s *  3221866504) 
(defvar  * i r i s 3  -  add r e s s *  3221866505) 

(defvar  *de s t - add r e s s *  nil) 


;  the  tcp-ip  or  internet  address 
;  look  in  network  configuration 


(defun  iris  (x) 

(cond  ((equal  x  1)  (setq  *de s t - addre s s *  *  i  r  i  s  1  - addre s  3*)  ) 
((equal  x  3)  (setq  *de s t - addr e s s *  *i ris3-address*) ) 

(t  (setq  *des t - addres s *  * i r i s2 - addre s s *) )  )  ) 

Figure  4.6  Encapsulation  of  IRIS  Addresses 


A  port  is  acquired  by  using  the  :  get-port  method  of  the  tcp-handler  flavor. 
Here,  shown  in  Figure  4.7,  we  use  the  global  instance,  ’’■tcp-handler*23  to  create  specific 
instances  of  the  Transmission  Control  Block  (TCB)  for  each  of  the  two  ports.  Only  the 
client  side  of  the  server/client  paradigm  has  been  implemented.  The  client  is  created  by 
using  the  (active  mode  argument  to  the  :open  method  of  the  tcp-port  flavor.  Both  the 
sending  and  receiving  ports  are  full  duplex,  but  are  only  used  in  a  simplex  mode.  Figure 
4.8  shows  the  creation  of  the  sending  port  [Ref.  28:  pp.  4-12 — 4-18]. 

The  three  fields  in  a  message  are  sent  and  received  separately.  Each  field  is 
then  treated  as  a  separate  object.  Figure  4.9  illustrates  sending  a  message.  For  all  fields, 
the  urgent  argument  is  specified  as  nil.  The  push  argument  is  specified  as  nil  until  the 


(defvar  * t cp - hand  1 e r 1  *  (send  i  p  :  : * t cp ■ hand  1  e r *  :get-port)) 
(defvar  *tcp-handler2*  (send  ip: :*tcp- handler*  :get-port)) 

Figure  4.7  Lisp  Port  Acquisition 


23  The  double  :  allows  the  tcp-handler  to  be  found,  since  it  was  not  created  "exportable"  in  the  Ip  package. 
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(send  talking-port  :open 
: ac  t i ve 

talking -port -number 
destination 


30  ) 


tcp  will  begin  the  procedure  to  establish 
connection  (default  vs  :passive) 
port  number  of  destination  host 
machine  name  or  address  if  blank  and 
in  {passive  mode  local  machine  waits  for 
connec  t i on 

set  max  seconds  before  read  request  times  out 


Figure  4.8  Opening  a  Lisp  Client  Connection 


(progn 
(  s  e 


nd  talking-port  : send 
typebuf  f  e  r 
1 

n  i  1 
nil  ) 

(if  (=  (length  1  eng t hbu f f e r )  4) 

(send  talking-port  : send 
lengthbuf fer 
4 

n  i  1 
nil  ) 

( progn 

(loopfor  *  1 oopvar i able*  (length  1  eng t hbuf f e r )  4 
(send  talking-port  :  send  "0"  1  nil  nil)  ) 

(send  talking-port  : send  lengthbuffer  (length  1  eng t hbuf f e r )  nil  nil)  )  ) 
(send  talking-port  : send 
buffer 

buffer- length 
t 

nil  )  ) 

Figure  4.9  Sending  a  Message 


data  buffer  is  sent,  when  it  is  specified  as  t.  The  entire  message  is  thus  sent  as  a  unit  to 
the  other  machine. 

2.  Symbolics  36xx 

Genera  7  syntactic  conventions  are  followed.  The  principle  difference  with 
Genera  6  conventions  is  in  the  definethod  function.  In  Genera  6  (and  the  TI  Explorer), 
the  method  name  follows  the  flavor  name.  In  Genera  7,  the  method  name  precedes  the 
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flavor  name.  Figure  4.10  shows  the  difference.  It  also  shows  the  other  main  difference 
with  the  earlier  code,  that  streams  are  used.  The  use  of  streams  improves  portability  and 
eliminates  the  need  for  the  :reuse-iris  method24.  It  may  be  slighdy  slower,  but  any 
difference  has  been  unnoticeable. 

Another  change  was  to  remove  the  dependence  on  hard-coded  addresses.  The 
method  :init-destination-host  was  added  to  the  conversation-with-iris  flavor  (see 
Figure  4.11).  By  using  the  net:parse-host  function,  the  application  need  only  know  the 
name  of  another  machine.  As  network  tables  are  updated,  no  change  to  the  application 
code  is  necessary  unless  a  different  machine  is  desired. 


(defmethod  (conversation-with-iris  :stop-iris) 
(  ) 

(progn  (send  talking-port  :close) 

(send  listening-port  :close)  )  ) 

Genera  6 

(defmethod  (:stop-iris  conve r sa t i on  -  wi  th - i r i s  ) 
(  ) 

(progn  (send  t a  Ik i ng- s t r earn  rclose) 

(send  1 i s t en i ng- s t ream  : c  lose )  )  ) 

Genera  7 

Figure  4.10  Genera  6  and  7  defmethod 


(defmethod  (  : i n i t - de s t i na t i on  -  ho s t  conversation-with-iris) 

( name  - o  f -  ho  s  t  ) 

(setf  de s t i na t i on  -  ho s t - ob j ec t  ( ne t : pa r s e - hos t  name - o f - ho s t  )  )  ) 

Figure  4.11  Generic  Host  Addressing 


21  The  :reuse-irls  method  is  retained  for  backward  compatibility. 


E.  Summary 

For  UNIX-based  machines,  generic  routines  are  developed  for  semaphore  use, 
shared  memory  use,  and  socket  use.  The  socket  routines  use  both  stream  sockets  and 
datagram  sockets  in  a  simplex  mode  to  provide  directly  connected  client/servers  and 
unconnected  broadcasting  communications.  IRIS  2400,  3120,  and  4D  systems  are  fully 
supported.  4.3BSD  systems  are  supported  with  mid-level  socket  calls  only. 

For  Lisp  machines,  stream-based  functions  are  available  for  direct  connection  as 
clients  only.  These  functions  are  available  directly  if  using  Genera  7  syntax  and  with 
minor  modification  if  using  Genera  6  syntax. 


I 


i 


% 

iVii 


v.  Use  by  Applications 


A.  introduction 


The  application  using  either  direct  connect  or  broadcast  protocol  is  not  concerned 
with  system-level  implementation  details.  Almost  all  aspects  of  shared  memory, 
semaphore,  and  socket  use  are  hidden.  The  number  of  other  machines  to  be  connected 
to,  the  use  of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  all 
that  concern  the  application  in  setting  up  a  connection.  The  synchronization,  or  lack 
thereof,  in  communication  between  machines  is  a  design  decision,  not  a  protocol 
decision. 


B.  Direct  Connect 

A  UNIX-based  machine  can  be  either  a  server,  waiting  for  a  client  to  call  and 
establish  a  connection,  or  the  client.  A  Lisp  machine  is  always  a  client. 

1.  UNIX-Based  Machines 

The  functions  provided  for  UNIX-based  machines  are  all  written  in  C.  They 
must  be  linked  into  the  application  program  using  them.  Figure  5.1  is  an  example  make 
file  for  creation  of  an  application  program  on  an  IRIS  system. 

There  are  two  independent  processes,  send  and  receive,  that  are  spawned  to 

create  the  sockets  and  monitor  them.  They  are  made  separately  with  the  makefile 25 
contained  in  their  subdirectory. 


1  See  Appendix  A 
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CFLAGS  =  -Zg  -  1m  -g  -p 

SHARE  =  /wo rk /ba r r ow/ s ha r e 3 / 

MMN  =  cars  imu  .  c 

OBJS  =  First  group  of  o  files 

OBJS1  =  Second  group  of  o  files 

OB  JS2  =  Third  group  of  o  files 

OBJS3  =  $( SHARE) i o_s i ngl e . o  \ 
$ ( SHARE  )mp  a  t  h  .  o  \ 

$( SHARE) semapho re . o  \ 
$(SHARE) share seg  .  o  \ 
$(SHARE) suppor t .o 

OB  J  S  4  =  Fifth  group  of  o  files 


cars imu :  $(M\IN)  $(OBJS)  S(OBJSl)  $(OBJS2)  $(OBJS3)  $(OBJS4) 

cc  -o  cars imu  $(MAIN)  $(OBJS)  $(OBJSl)  $(OBJS2)  $(OBJS3)  $(OBJS4)  $(CFLAGS)  -Ibsd 

$(M\IN)  :  const. h  vars.h 

$(OBJS):  const.h  vars.h 

$(OBJSl):  const.h  objects. h 

$(OBJS2):  const.h 

$( SHARE)mpa t h  .  o  :  $ (SHARE) s ha  red  .  h 

cc  -c  -o  $( SHARE )mpa t h . o  $( SHARE )mpa t h . c  $(CFLAGS) 

S( SHARE) suppor t  .  o  :  $( SHARE) sha red . h 

cc  -c  -o  $( SHARE) suppor t . o  $(StMRE) suppor t . c  S(CFLAGS) 


y 


$( SHARE) semaphore . o : 

cc  -c  -o  $( SHARE) semapho re . o  $ (SHARE) s emaphore . c  $(CFLAGS) 

$( SHARE) i o_s i ng 1 e . o :  $( SHARE) s ha  red . h 

cc  -c  -o  $( SHARE) i o_ s i ng I e , o  S ( SHARE) i o_ s i ng { e . c  $(CFLAGS) 

$ ( SHARE )shareseg.o: 

cc  -c  -o  $( SHARE) sha re seg . o  $( SHARE) s ha r e s e g . c  $( CFLAGS) 

Figure  5.1  Sample  Application  make  File 


a.  Application  Setup 


Sal 


K/'l 


The  server  process  must  be  started  first.  Tlie  application  can  set  up  the 
communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response  to  a 
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specific  operator  command.  In  either  case,  there  will  be  two  messages  returned  to  the 
terminal  for  each  direct  connection  setup.  Figure  5.2  illustrates  a  normal,  single 
connection,  response.  Since  the  receive  and  send  processes  that  provide  the  messages 
are  independent,  the  two  lines  shown  may  be  jumbled.  A  variety  of  errors  can  occur  at 
this  point.  Table  5.1  gives  the  most  common  error  messages,  their  cause,  and  solution. 


Server  waiting  to  connect  to  name 
Server  waiting  to  connect  to  name 


Figure  5.2  Normal  Server  Response 


Table  5 . 1  SERVER  ERROR  RESPONSES 


Message 

Cause 

Solution 

Server  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ¬ 
ous  run  not  terminating 
with  deletemachinepalh 

Run  ps.  Use  kill  to  ter¬ 
minate  any  receive  or  send 
processes  still  running 

Server  couldn't  bind  address  to  local  socket: 

Socket  in  use  due  to  previ¬ 
ous  run  not  terminating 
with  deletemachinepath 

Run  ps.  Use  kill  to  ter¬ 
minate  any  receive  or  send 
processes  still  running 

shmget:  Permission  denied 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
owned  by  another  uid 

Change  key  in 

machinepath  call,  recom¬ 
pile,  and  rerun 

shmget:  Invalid  argument 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
too  small  because  the  value 
of  LARGES'  1  READ  has 
been  increased 

Run  rmshare  and  rerun  ap¬ 
plication 

slimat:  Permission  denied 

Someone  >  .se's  send  or  re¬ 
ceive  process  is  being 
spawned 

Outdated  software  is  being 
used. 

Check  that  proper  path  is 
used  in  shared.lt,  for 
application's  include  of 
shared.lt,  and  in 

application’s  Makefile. 

Correct  and  recompile. 

Ensure  that  all  modules  are 
the  most  current.  If  some 
are  not.  get  updated 
modules  and  recompile — 
especially  send  and  re¬ 
ceive. 
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The  client  process  must  not  attempt  connection  until  after  the  server  is 
properly  running  (the  messages  in  Figure  5.2  have  been  received).  The  application  can 
set  up  the  communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response 
to  a  specific  operator  command.  When  client  communications  setup  is  part  of  the 
initialization,  care  must  be  taken  to  wait  for  a  ready  server  before  starting  the  client.  In 
either  case,  there  will  be  two  messages  returned  to  the  terminal  for  each  direct 
connection  setup.  Figure  5.3  illustrates  a  normal,  single  connection,  response.  Since  the 
receive  and  send  processes  that  provide  the  messages  are  independent,  the  two  lines 
shown  may  be  jumbled.  A  variety  of  errors  can  occur  at  this  point.  Table  5.2  gives  the 
most  common  error  messages,  their  cause,  and  solution, 
b.  Coding  Practices 

(1)  Connection.  Making  a  connection  requires  two  acts.  The  first  is  to 
set  aside  space  for  the  data  required.  Figure  5.4  shows  this  code  when  local  declaration 
is  used.  The  Machine  structure  can  also  be  declared  globally.  The  second  is  to  request 
the  connection  with  a  machinepath,  dynamicmachinepath,  or  dynamicmachinepaths 
call.  Table  5.3  compares  the  three  types  of  call,  while  Figure  5.5  gives  a  server  example 
for  dynamicmachinepath.  A  description  of  the  parameters  used  is  in  Appendix  A, 
Section  2.  a. 

For  flexibility,  there  is  often  a  requirement  for  command  line 
specification  of  the  machine  to  be  connected  to.  For  ease  of  use,  there  is  often  a 


Connection  established  with  name 
Connection  established  with  name 


Figure  5.3  Normal  Client  Response 


Table  5 . 2  CLIENT  ERROR  RESPONSES 


Message 

Cause 

Solution 

Client  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ¬ 
ous  run  not  terminating 
with  deletemachinepath 

Run  ps.  Use  kill  lo  ter¬ 
minate  any  receive  or  send 
processes  still  running 

Client  couldn't  connect  to  the  remote  server  socket: 

The  server  has  not  success¬ 
fully  started 

The  port  numbers  used  by 
client  do  not  correspond  to 
those  of  server 

Terminate  client,  restart 
server,  restart  client  when 
server  started 

Correct,  recompile,  and 
rerun 

stun  get:  Permission  denied 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
owned  by  another  uid 

Change  key  in 

machinepath  call,  recom¬ 
pile,  and  rerun 

shmget:  Invalid  argument 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
too  small  because  the  value 
of  LARGESTREAD  has 
been  increased 

Run  rmshare  and  rerun  ap¬ 
plication 

slunat:  Permission  denied 

Someone  else's  send  or  re¬ 
ceive  process  is  being 
spawned 

Outdated  software  is  being 
used. 

Check  that  proper  path  is 
used  in  shared.h,  for 
application's  include  of 
shared.h,  and  in 

application's  Makefile. 

Correct  and  recompile. 

Ensure  that  all  modules  are 
the  most  current.  If  some 
are  not,  get  updated 
modules  and  recompile — 
especially  send  and  re¬ 
ceive. 

#i nc lude  " /work/ba r  row/ share3/shared.h" 
ma  i  n ( a  r gc  ,  a  r gv  ) 

LOCAL  DECLARATIONS 

Machine  cardriver;  /*  structure  for  conniun i c a t i on s  system  */ 


Figure  5.4  Creation  of  Machine  Structure 
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Table  5.3  PATH  CONNECTION 


Function 

Purpose 

machinepath 

Creates  a  link  between  two  machines 

No  subsequent  dynamic  memory  allocation  al¬ 
lowed 

dynamicmachinepath 

Creates  a  link  between  two  machines 

Subsequent  dynamic  memory  allocation  allowed 

dynamicmachinepaths 

Creates  a  link  between  two  machines 

Subsequent  dynamic  memory  allocation  allowed 
Multiple  calls  provide  multiple  links  to  one  or 
more  other  machines 

ma  in(argc.argv) 

SYSTEM  INITIALIZATIONS 

/*  Open  up  the  net  path  to  other  machine  (iris3  default)  */ 
dynamicmachinepa  th( 2 , o t he  r_machine .4, 5, "server" ,&cardr i ve  r , 2000000 ) ; 

Figure  5.5  Server  Creation 


requirement  for  a  default  specification.  Figure  5.6  illustrates  one  way  to  accomplish  this 
for  a  client.  This  example  does  not  require  that  the  network  alias  be  defined  to  die 
system  as  it  uses  the  complete  address.  The  user,  however,  only  enters  the  alias. 

(2)  Program  Use.  The  simplest  high-level  communication  paradigm  is 
reading  from  and  writing  to  the  other  machine.  It  closely  parallels  handling  files  and 
terminals  in  C.  It  was  chosen  for  these  reasons. 

Twelve  high-level  functions  are  available.  Four  provide  status 


information,  four  write  to  other  jnachine ,  and  four  read  from  other  jnachine.  Table  5.4 
describes  these  functions.  The  parameters  used  by  these  calls  are  described  in  Appendix 
A,  Sections  l.a  and  9. a. 


ma in(argc,nrgv) 

int  argc;  /*  argument  count  */ 

char  *argv[ | ;  /*  pointers  to  the  passed  in  arguments  */ 


DATA 


DECLARATION 


char  other  machine[50l; 


/*  name  of  other  machine  */ 


SYSTEM 


INITIALIZATIONS 


/  *  pull  out  the  string  fr  om  the  a  r  g  ume  n  t  list  *  / 
i  f ( argc  >  2) 

( 

printf("NAV:  incorrect  argument  count!  use  nav  <alia3>\n"); 
ex i t ( 1 ) ; 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
i  f  (  a  rgc  ==  2  ) 

I 

strcpy(  other_machine ,  "npscs-"  ): 
strcatf  other_machine ,  argv[l]  ); 


strcpy(  other_machine ,  " npsc s - i r i s 2"  ); 

/*  Open  up  the  net  path  to  other  machine  (iris2  default)  */ 
dynami  cmach inepath(2,othe  r_mach i ne, 5, 4, "client" ,&ca  r , 2000000 ) ; 

Figure  5.6  Command  Line  Direction  for  Connection 


There  is  a  variety  of  ways  to  use  these  functions.  Figure  5.7 
illustrates  a  typical  scenario.  This  code  is  from  the  display  station  of  a  two-workstation 
driver  simulation.  The  display  station  provides  its  status  (that  of  the  “world”)  on  each 
pass  through  its  graphical  display  loop.  The  control  station  must  read  that  status  on  each 
pass,  to  update  the  vehicle  position  on  its  track  diagram.  On  each  pass,  the  display 
station  checks  to  see  if  any  commands  have  been  received.  This  is  an  asynchronous 
communication,  as  the  display  station  continues  with  or  without  a  control  station 
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command.  The  asynchronous  reads  are  guarded  by  a  receiver _has data  call  that  detects 
arrival  of  a  message.  Other  receiver _has_data  calls  are  used  to  “busy  wait”  for  the  next 
message.  In  practice,  it  has  not  been  necessary  to  include  any  but  the  first  “busy  wait” 
receiver  Jiasjiata  call.  TCP/IP  buffers  messages  when  they  are  not  immediately  read. 
It  then  blocks  them  into  the  largest  grouping  possible  and  delivers  them  when  the  next 
read  occurs.  The  LARGESTREAD  defined  constant  in  shared. h  determines  this 
maximum  grouping.  The  first  message  is  read  by  receive.  The  socket  is  then  ignored 
until  the  application  reads  the  data.  During  this  time,  the  other  messages  have  all  been 
sent  and  buffered  by  TCP/IP.  There  is  a  slight  delay  between  the  time  the  first  message  is 
read  and  the  block  containing  all  the  rest  is  read.  Thus  the  necessity  for  the  first  “busy 
wait”  receiver  has  data  call.  The  other  “busy  wait”  receiver  has  data  calls  are  simply 
for  robustness. 

The  “busy  wait”  sender  jsjree  call  determines  if  something  has 
happened  to  the  other  machine  or  Ethernet.  The  first  write  will  always  succeed,  as  it  goes 
to  a  buffer.  If  there  is  a  communications  problem,  TCP/IP  will  not  accept  it  and  the 

Table  5.4  COMMUNICATION  FUNCTIONS 


Function 

Action 

senderjsjfree 

receiver_has_data 

received_type 

number jrece  ived 

Returns  TRUE  if  a  message  can  be  sent. 

Returns  TRUE  if  a  new  message  has  been  received. 

Returns  a  character  indicating  the  type  of  the  message.  CHARACTER_TYPE. 
INTEGER JTYPE,  and  FLOAT_TYPE  are  predefined.  CHARACTER_ARRAY_TYPE, 
INTEOER_ARRAY_TYPE,  and  FLOAT_ARRAY_TYPE  are  predefined. 

Returns  an  integer  indicating  how  many  elements  in  message. 

write_character 

write_integer 

write_float 

write_characters 

Send  a  single  value  of  the  type  to  other  machine. 

read_character 

read_integer 

read_float 

read_characters 

Move  single  value  of  named  type  from  buffer  to  application  program  storage. 

ma  i  n ( a  r gc , a  r  gv ) 


MAIN 


S  IMULAT  I  ON 


LOOP 


wh i 1 e ( veh i c I e . command . condi t i on  !=  DONE) 
{ 


Get  commands  (if  any)  from  navigator.  Commands  are  all  sent 
or  none  are  sent  so  no  information  is  needed  as  to  which  value 
is  which. 

'/ 


if(  r ece i ve r_has_da t a(  &cardriver  )  ) 

( 

read_ integer (Ac a r d r i ve r ,  &veh i c i e . command .condi tion) ; 
while(  ! r ece i ve r_ha s_da t a (  &cardriver  )  )  / *p r i n t f ( " 1 " ) ♦ / 

read_i n  t eger (Acardr iver,  Avehi c le  . command . brakepedal ) ; 
while(  ! r ece i ve r_ha s_da t a(  Acardriver  )  )  / *pr in t f ( ”2" ) */ 
read_in t egc r(&cardr iver,  Aremot e_mousex ) ; 

while(  !  receiver_has_data(  Acardriver  )  )  /  *pr  in  t  f  ( ’’  3”  )  *  / 
read_float (Acardriver ,  Acmdspeed) ; 


Report  all  status  information  to  navigator  every  cycle. 


wr i t e_floa t (Acardr iver,  Aveh icle.state_vector[l]); 

while(  ! sender_i s_f ree(Acardr i ver )  )  pr i n t f ( ”b" ) : 

wr  i t  e_floa t (Acardr iver,  Avehicle.state_vector[2]); 

wr  i t e_floa  t (Acardr iver,  Aveh ic 1 e . s  t  a  t e_vec  t  or [ 3 ] ) ; 

wri  te_float (Ac  a  rdr i ve  r ,  Aveh icle . situat ion.distance_t  raveled)  ; 

write_integer (Ac a rd r i ve r ,  Aveh icle. command .condition); 

wri te_integer (Ac  a  r dr i ve  r  ,  Aveh i c 1 e . c onrnand .brakepedal ) ; 

wri  te_integer (Ac  a  r d  r i ve  r ,  Aveh i cle.  situation,  lightcolor); 


)  /‘while  1 oop  * / 


I  / *  ma in  * / 


Figure  5.7  Synchronous  Write  /  Asynchronous  Read 


sender  Js  Jree  call  will  return  FALSE.  This  often  occurs  when  there  is  a  delay  by  the 
client  in  connecting  to  the  server  (the  display  station  here).  If  there  is  a  good  connection, 
TCP/EP  will  accept  and  buffer  all  input.  No  other  “busy  wait”  calls  are  needed.  The  other 
side  of  the  communication  is  shown  in  Figure  5.8. 

(3)  Disconnection.  Termination,  with  a  deletemachinepath  call  for 
each  path  opened,  is  mandatory.  If  not  performed,  the  sockets  (and  shared  memory 
segment  on  System  V  UNIX  machines)  will  not  be  returned  to  the  system.  Problems26 
may  then  occur  on  the  next  run.  Figure  5.9  is  an  example  termination  when  multiple 
paths  have  been  opened  [Ref.  11]. 

2.  Lisp  Machines 

All  necessary  functions  are  contained  in  a  single  file.  This  file  must  be  loaded 
before  use.  Figure  5.10  is  an  example.  A  Lisp  machine  is  always  a  client  and  is  started 
second.  Figure  5.11  illustrates  the  message  returned  with  a  successful  connection. 
Unsuccessful  connections  “hang”  and  return  nothing, 
a.  Connection 

The  address  of  the  server  and  the  ports  it  is  using  must  be  specified. 
Figure  5.12  shows  the  ports  specified  as  part  of  the  loaded  file.  When  using  the  older  TI 
Explorer  functions,  the  addresses  are  specified  in  the  same  way  (see  Figure  4.5)  and  then 
the  machine  desired  is  requested  by  number27  (shown  in  Figure  5.13).  When  using  tire 
stream-based  functions,  the  addresses  are  not  specified  by  the  user  at  all.  The  network 
tables  are  accessed,  by  host  name,  through  the  select-host  function  provided  (shown  in 
Figure  5.14).  Once  the  instance  of  conversation-with-iris  flavor  has  been  completed 


z6  See  Tables  5. 1  and  5.2 

v  A  throwback  to  connection  only  with  different  IRIS  machines. 


ma  i  n  (  a  rgc  ,  a  rg  v  ) 


wh  i 1 e ( cond i t i on  !=  DONE) 


Receive  all  status  information  from  car  every  cycle. 


while(  !  r ece  i  ve r_ha s_da t a (  &car  )  ) 
re ad_floa  t  (&c a r  ,  &cy); 
while(  ! r ece i ve r_ha s_da t a (  &car  )  ) 
read_floa t (&car ,  &cx); 
while(  ! rece i ve r_ha s_da t a (  &car  )  ) 
r  ead_floa  t  (&c  a  r  ,  &velocity); 
while(  ! r ece i ve r_ha s_da t a (  &c a r  )  ) 

read_floa t  (&ca r ,  &rdi stance) ; 
while(  ! r ece i ve r_ha s_da t a (  &car  )  ) 

read_ i n t ege r (&ca r  ,  ^condition); 
while(  ! receiver_has_dat a(  &car  )  ) 
read_ integer (&ca r ,  &br akepos i t i on ) ; 
while(  ! r ece i ve r_ha s_da t a (  &car  )  ) 

re ad_ i n t ege r (&c a r ,  &1  i gh t co 1 o r ) ; 


Send  conmnands  (if  any)  to  car.  Commands  are  all  sent 

or  none  are  sent  so  no  information  is  needed  as  to  which  value 

is  which. 


i  f ( any  t  h i ng_h a s_c hanged ) 

I 

any t h i ng_has_changed  =  FALSE; 

wri  t  e_  i  n  t  C(je  ;  'iv  u  i  ,  Acond  >  t  i  on  )  ; 

while(  ! sender_i s_f ree(  &car  )  )  printf("a") 

wri te_integer (Ac a r ,  Ab rakeposi t ion) ; 

while(  !  sende r_i s_f r ee (  &car  )  )  printf(”b") 

wr i t e_ i n t ege r  (&c a r ,  &nousex): 

wh i 1 e (  ! s ende r_ i s_f ree (  Ac  a  r  )  )  printf("c”) 

wr i t e_floa t  (&c a r ,  Acmdve l oc i t y ) ; 

)  /*  i  f ( any t h i ng_ha s_changed )  */ 


I  / *  white  * / 


I  / *  ma in  * / 

Figure  5.8  Reciprocal  Synchronous  Read  /  Asynchronous  Write 


de 1 e  t emach i nepa  t  h (&TI ) ; 
de  1  e  t  emach  i  nepa  t  h (&SVM3  )  ; 
de  1  e  t  emach i nepa  t  h (&SVM1  ) ; 
dele  t  emac  hi  nepa  th(&S'¥M4)  ; 


exi t ( ) : 


Figure  5.9  Connection  Termination 


;;;  this  is  the  comnun i ca t i on  package 
(load  " i r  i  sflavo  r " ) 


Figure  5.10  Loading  Lisp  Flavor 


"A  conversation  with  the  iris  machine  has  been  established’ 


Figure  5.11  Lisp  Connection  Message 


(defvar  *  i  r i s  1  - por 1 1  *  1027) 
(defvar  *  i  r  i  s 1 -por t2*  1026) 


;  this  is  the  send  port 
;  this  is  the  receive  port 


Figure  5.12  Setting  Port  Numbers  with  defvar 


get  the  network  going 
(iris  1  ) 

(setq  *battle*  (make - i ns t ance  ’ con ve r s a t i on -wi t h - i r i s ) ) 

(if  (y-or-n-p  "start  networking  7")  (send  ‘battle*  :  s t a r t  -  i  r  i  s  )  ) 

Figure  5.13  Specifying  Server  in  Lisp 


m 


m 


(select- host  iris2) 


Figure  5.14  Specifying  Server  by  Name  in  Lisp 


with  port  numbers  and  host  addresses,  the  connection  is  established  with  the  method 
:start-iris,  see  Figure  5.13. 

b.  Program  Use 

The  method  :get-iris  returns  with  the  object  sent  by  one  message.  The 
method  (:put-iris  object)  sends  the  object  as  one  message.  Figure  5.15  illustrates  both. 
Note  how  methods  are  added  to  flavor  conversation-with-iris  to  simplify  the 
application  interface  even  further.  [Ref.  11] 

c.  Disconnection 


Disconnection  is  accomplished  with  the  method  :stop-iris,  shown  in 


Figure  5.16. 


C.  Broadcast 

Only  UNIX-based  machines  support  our  broadcast  protocol  at  this  time.  It  is  a 
unidirectional  protocol,  but  nothing  prevents  the  establishment  of  two  unidirectional 
channels  in  opposite  directions.  Using  two  broadcast  channels  to  emulate  a  direct 
connect  channel,  however,  loads  all  other  machines  on  the  network  by  requiring  every 
other  machine  to  process  each  message.  It  is  also  less  reliable.  Broadcasting  is  good  for 
sending  status  information  to  many  other  machines,  as  long  as  those  machines  can 
tolerate  missing  reports. 

1.  Similarities  With  Direct  Connect  Protocol  Use 

Using  the  broadcast  protocol  is  similar  to  using  the  direct  connect  protocol. 
The  same  functions  are  used  in  the  same  way.  Each  connection  must  set  aside  space  as 
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BB 


Uefin i t i on  s 


object 


name:  character  "1"  ..  "5" 

x  coordinate:  real 
y  coord i na  t  e :  real 
z  coordinate:  real 

speed:  real  speed  of  ve 

direction:  real  compass  dir 


speed  of  vehicle  -10.00  to  25.00 
compass  dir  in  degrees  from  GN 


in  lisp  ("n”  (x  y  z  spd  dir)) 


;;;  get  an  object  in  graphics  environment  (defined  as  above) 

(defmethod  ( conve r s a t i on -wi t h - i r i s  :object) 

() 

(makeob j 

(  send  self  : get-iris) 

( send  self  : get-iris) 

(  send  self  : ge  t -  i  r  i  s  ) 

(  send  self  : get-iris) 

(send  self  :get-iris) 

(send  self  :get-iris)  )  ) 

;;;  vision  returns  a  list  of  objects  in  the  tank's  field  of  vision  (100m  radius) 
;;;  this  is  effectively  an  association  list 

(defmethod  ( conve r sa t i on -wi t h- i r i s  :vision) 

( t  ank) 

(let  ( (field  nil) 

(n-objects  0)  ) 

(progn  (send  self  :put-iris  "V") 

(send  self  :put-iris  tank) 

(if  (equal  "V"  (send  self  : ge t - i r i s ) ) 

(progn  (setq  n-objects  (send  self  :get-iris)) 

( do  t  ime  s 

(x  n-objects  field) 

(setq  field  (cons  (send  self  :object)  field))  )  ) 

(progn 

(print  "iris  did  not  respond  to  the  vision  comaand  sent  from  ") 
( p  r i nc  " t  ank  "  ) 

(princ  tank)  )  )  )  )  ) 

Figure  5.15  Application  Communication  in  Lisp 


in  Figure  5.4.  The  same  criteria  for  using  a  specific  machinepath  call  apply  (see  Table 
5.3).  The  same  communications  functions  are  available  as  in  Table  5.4.  Each 
connection  must  be  terminated  as  in  Figure  5.9. 


(if  (y-or-n-p  "stop  iris  connection  ?“)  (send  ’battle*  :stop-iris)) 


Figure  5.16  Termination  of  Communications  in  Lisp 


2.  Differences  With  Direct  Connect  Protocol  Use 
a.  Application  Setup 

The  broadcast  protocol  is  not  directly  modeled  as  a  server/client 
relationship.  The  broadcaster  broadcasts  to  whomever  is  prepared  to  receive.  The 
receiver  must  be  ready  and  so  must  be  started  first.  Since  the  broadcaster  is  more  similar 
to  the  server  in  a  server/client  model,  this  connection  order  seems  exactly  backward.  No 
error  will  result  if  the  broadcaster  starts  first,  messages  will  simply  not  be  received.  The 
receiver  message  is  shown  in  Figure  5.17.  The  broadcaster  message  is  shown  in  Figure 
5.18.  When  a  direct  connect  channel  is  also  required  between  the  same  two  machines, 
achieving  proper  startup  order  is  easy.  Establish  the  direct  connect  channel  first,  then  the 
soon-to-be  broadcasting  process  sends  a  message  telling  the  receiver  to  start  up.  Once 
started,  the  receiver  process  sends  a  message  permitting  the  broadcaster  to  start. 


ready  to  receive  from  broadcaster _name 

Figure  5.17  Normal  Receiver  Response 


Waiting  to  broadcast 


14 


a 


Figure  5.18  Normal  Broadcaster  Response 
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b.  Coding  Practices 

The  parameters  to  the  machinepath  family  of  functions  are  used 
differently  for  the  broadcast  protocol.  All  are  required  to  be  present,  but  some  are 
ignored  (see  Table  5.5).  Since  a  broadcast  channel  is  unidirectional,  the  receive jype 
application  calls  are  meaningless  to  the  broadcaster  (the  receiver _has_data  call  always 
returns  false).  The  sendjype  application  calls  are  meaningless  to  the  receiver  (the 
sender  JsJree  call  always  returns  false). 

D.  SUMMARY 

Using  the  same  functions,  an  application  can  either  broadcast  or  directly  connect  to 
another  machine.  The  same  steps  of  setup,  connection,  use,  and  termination  are  common 
to  both  protocols.  Care  must  be  taken  in  the  timing  of  the  two  (or  more)  machines  setup. 
After  that,  an  application  merely  reads  or  writes  data. 
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Table  5.5  MACHINEPATH  PARAMETERS 


Parameter 


nummachines 


Function 


dvnamicmachinepath 


dvnamicmachinepaths 


Number  of  channels  that  could 
be  created  by  application.  This 
includes  both  DIRECT  CON¬ 
NECT  and  BROADCAST  chan¬ 
nels. 


Arbitrary  integer.  Should  be  different  than  another 

user’s  application.  _ 

Only  first  call’s  value  used. 


DIRECT  CONNECT  and  BROADCAST  ( receiver 
only):  Name  of  machine  to  connect  to. 


BROADCAST  ( broadcaster  only):  Required  but  ig¬ 
nored 


DIRECT  CONNECT:  Number  (0-3076)  of  port  to  be 
used  to  send  to  other  machine. 


BROADCAST  ( broadcaster  only):  Number  (0-3076) 
of  port  to  be  used  for  broadcast. 


BROADCAST  ( receiver  only):  Required  but  ignored 


DIRECT  CONNECT:  Number  (0-3076)  of  port  to  be 
used  to  receive  from  other  machine. 


BROADCAST  ( broadcaster  only):  Required  but  ig¬ 
nored 


BROADCAST  ( receiver  only):  Number  (0-3076)  of 
port  to  be  used  for  broadcast. 


"server":  Create  DIRECT  CONNECT  channel 


"client": 


"broadcast". 


receive  : 


as  a  server. 


Create  DIRECT  CONNECT  channel 
as  a  client. 


Create  BROADCAST  channel  as  a 
broadcaster. 


Create  BROADCAST  channel  as  a 
receiver. 


Address  of  Machine  structure  created  to  hold  channel 
information. 


Amount  of  space  to  be  used  for 

N/A  dynamic  memory  allocation. _ 

Only  first  call's  value  used. 


VI.  Performance 


A.  INTRODUCTION 

We  look  at  the  size  of  packets  from  our  protocols.  We  also  look  at  the  effect  of  real 
applications  on  the  network.  We  try  to  do  this  for  both  direct  connect  and  broadcast 
protocols.  However,  no  application  making  good  use  of  broadcast  protocols  exists. 
Hence,  we  used  a  direct  connect  test  application  and  replaced  the  channel  with  two 
broadcast  channels. 

B.  DATA  COLLECTION 

The  LANalyzer*  EX  5500  network  analyzer  was  used  to  gather  Ethernet  statistics. 
Version  2.0  of  the  software  was  used.  The  LANalyzer  5500  is  a  COMPAQ  PORTABLE 
II**  with  a  coprocessor  board  installed.  The  coprocessor  board  has  an  Intel  80286  CPU, 
an  Intel  82586  LAN  coprocessor,  and  two  MBytes  of  memory.  It  performs  packet 
collection,  packet  filtering,  and  network  statistics  calculation.  The  COMPAQ  PORTABLE 
II  processor  handles  user  software  control,  screen  updating  and  disk  I/O.  [Ref.  29] 

Samples  were  taken  while  direct  connect  applications  were  running  on  iris2  and 
iris3.  To  compare  direct  connect  protocol  with  the  broadcast  protocol,  test  programs 
were  used  .  Table  6.1  summarizes  the  information  collected.  These  programs  send  a 
character  string,  an  integer,  and  a  floating  point  number  in  a  rotating  sequence.  The 
messages  are  either  sent  to  the  machine  specified  on  the  command  line  or  are  broadcast 
to  all  machines  on  the  local  network  but  only  received  from  the  machine  specified. 


*  LANalyzer  is  a  registered  trademark  of  Exceian,  Inc. 

COMPAQ  PORTABLE  II  is  a  tradmark  of  the  COMPAQ  Computer  Corporation. 
2"  See  programs  prog  c.  progl.c,  gprog.c,  and  gprng2.c  in  Appendix  D. 
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RECT  CONNECT  VERSUS  BROADCAST  STATISTICS 

1 

Run 

Number 


Broadcast 
Number  Ave 

of  Packet 

Packets  ^Ze 

(by1**) 

Max 

Test 

Load 

(%) 

9498 

69 

1.0 

9860 

69 

1.0 

4000 

68 

1.0 

2556 

68 

1.0 

1262 

68 

1.0 

The  visual  simulation  application  measured  was  a  modified  version  of  the  driving 
simulator  [Ref.  7].  Table  6.2  summarizes  the  information  collected.  This  data  was 
taken  during  the  day29.  The  application’s  communication  code  is  shown  in  Figure  5.7 
and  Figure  5.8.  One  trip  around  the  track  took  approximately  five  minutes.  Seven 
messages  are  sent  every  cycle  to  report  status.  Four  messages  arc  sent  in  the  opposite 
direction,  as  required,  to  control  the  car.  One  circuit  was  driven,  on  autopilot,  for  each 
test  run.  There  were  about  500  cycles  per  test.  Approximately  3600  messages  were 
generated  per  test.  The  number  of  packets  sent  was  less  than  half  of  this.  The  apparent 
discrepancy  exists  for  two  reasons.  First,  each  packet  sent  also  generates  an 
Table  6.2  APPLICATION  NETWORK  USE  STATISTICS 
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2848 

89 
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22830 

89 

17 
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At  night,  with  less  competition  for  network  resources,  the  results  were  similar. 
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acknowledgement  packet  in  return.  By  acknowledging  each  packet,  the  stream  socket 
guarantee  of  delivery  and  proper  sequence  is  met.  Second,  after  the  first  packet 
(containing  the  first  message)  is  received,  the  remaining  three  or  six  messages  are 
immediately  sent.  The  receiving  process  has  often  not  yet  handled  the  first  one.  The 
remaining  messages  are  combined  into  one  and  all  are  read  as  one  block.  This  reduces 
the  interchange  to  a  typical  total  of  four  packets  per  cycle,  two  with  data  and  two  for 
acknowledgement.  Similarly,  four  packets  are  usually  generated  whenever  the  navigator 
process  issues  a  command  sequence  to  the  car. 

An  evaluation  of  a  five-workstation  application  [Ref.  11]  was  also  made.  This 
application  used  three  Symbolics  ( syml ,  sym3,  and  sym4),  expl,  and  iris2  to  perform  its 
tasks.  Statistics  were  similar  to  the  other  application,  but  the  Symbolics  irisflavor.lisp30 
exhibited  some  problem  behavior.  It  sent  three  packets  for  every  message.  The  first 
packet  contained  the  type  field  only.  The  second  packet  contained  both  the  type  field 
and  the  length  field.  The  third  contained  the  entire  message.  If  a  second  message 
immediately  followed  the  first,  three  more  packets  were  sent,  each  adding  one  field  to  the 
previous  packet.  Only  one  acknowledgement  was  received,  as  all  packets  in  a  group  had 
the  same  identification  number. 

C.  DISCUSSION 

Attempting  to  use  broadcast  protocol  with  the  simple  test  programs  failed.  One 
problem  encountered  was  overflow  of  the  sending  buffer  within  the  TCP/IP  layers.  The 
rapidity  of  attempted  transmission  was  the  cause.  Higher  network  loading  exacerbated 
the  problem.  When  the  test  application  was  slowed  down  with  printf  calls  (and  the 
output  redirected  into  a  file)  the  buffer  could  keep  up  with  sending  requests.  Using 

30  See  Appendix  C 


broadcast  protocol  within  a  graphics  display  loop  should  pose  no  problems  unless 
numerous  data  elements  are  transmitted  at  one  time. 

Without  acknowledgement  packets,  broadcasting  put  fewer  packets  on  the  network 
than  did  the  direct  connect  protocol.  When  overall  load  was  haevy,  some  were  lost.  This 
poses  a  serious  problem  for  visual  simulation  applications.  Without  an  elaborate 
application-level  protocol,  the  receiving  process  will  never  know  what  was  intended  to 
be  sent.  Since  only  one  data  object  is  transmitted  at  a  time,  labeling  the  data  objects  is 
difficult.  All  that  is  available  is  to  alternately  send  different  types  and,  after  checking 
the  type  received,  make  a  determination  of  the  likely  intent  of  the  sending  process.  If  a 
block  of  data,  containing  different  types,  could  be  sent  as  a  single  message,  the  decoding 
problem  would  become  one  of  simply  sequence  checking.  Missing  status  packets  can  be 
safely  ignored  in  many  situations.  At  most,  a  simple  averaging  algorithm  can  smooth 
any  discontinuities  caused  by  a  missing  packet.  Timestamping,  with  a  virtual  timestamp, 
of  each  packet  would  eliminate  the  averaging  requirement. 

The  Symbolics  stream  version  is  much  less  efficient,  in  terms  of  network 
utilization,  than  is  the  Explorer’s.  It  still  functions  correctly,  with  no  noticeable  delay. 
As  the  amount  of  data  to  transmit  increases,  the  Symbolics  flavor  will  eventually  have 
noticeable  performance  degradation. 

The  interconection  of  five  machines  loads  the  network  only  slightly  more  than  does 
that  of  two.  The  limitation  will  be  from  the  process  swap  overhead,  not  the  network. 

D.  SUMMARY 

The  direct  connect  protocol  sends  fewer  packets  than  messages.  Half  of  the  packets 
sent  are  acknowledgements.  These  acknowledgements  provide  the  reliability  of  the 
direct  connect  protocol.  Tire  broadcast  protocol  sends  one  packet  for  each  message. 
These  packets  tend  to  be  smaller  than  those  for  the  direct  connect  protocol.  Until  a 


mechanism  exists  to  bundle  several  messages  into  one  broadcast  packet,  the  broadcast 
protocol  is  of  small  value. 


sisgvsw 


VV\  S 

»  j  j  r  i 


vn.  Conclusions  and  recommendations 


A.  LIMITATIONS 

There  are  two  primary  limitations.  First,  the  Lisp  and  C  functions  differ  at  the  user 
level.  This  was  done  to  allow  each  to  be  used  readily  by  programmers  “thinking”  in  their 
respective  language.  We  have  found  this  to  be  confusing  to  students  who  are 
inexperienced  in  both  languages.  Second,  there  is  no  simple  means  to  transmit  a  block  of 
data  or  an  entire  file.  Each  data  element,  unless  it  is  part  of  an  array  of  characters,  must 
be  sent  separately.  This  was  done  to  “hit  a  middle  ground”  between  a  complex 
facility — printf  function — and  low-level  system  calls.  As  long  as  only  the  direct  connect 
protocol  existed,  this  was  only  an  annoyance.  As  discussed  in  Chapter  6,  this  is  a 
critically  limiting  factor  for  the  broadcast  protocol. 

The  port  to  BSD  UNIX  systems  without  shared  memory  and  semaphores  was  not 
completed.  The  socket  handling  aspects  are  portable,  but  the  shared  memory  aspects  are 
interwoven  throughout  the  system.  The  difficult  part  of  the  porting  will  be  designing  the 
message-passing  protocol  for  the  pipe  between  the  application  and  the  send  and  receive 
processes,  as  discussed  in  Chapter  4.  Other  specific  limitations  include: 

•  no  broadcast  capability  for  Lisp  machines 

•  no  server  capability  for  Lisp  machines 

•  limited  communication  error  handling — no  signals  are  sent  from  the  send  or  receive 
processes  to  the  application  process  if  they  encounter  problems 

•  limited  read/write  error  handling — a  read  or  write  of  the  wrong  type  will  be 
attempted  and  usually  produce  garbage 

•  no  out-of-band  capability 

•  Symbolics  iris-flavor.lisp  creates  three  packets  per  message 
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B.  Future  Research  Areas 

Implementation  of  the  missing  structure  data  type  is  one  key  area  in  which  more 
work  could  be  done.  The  most  straight-forward  solution  to  this  would  be  to  add 
messages  to  the  send  section  of  the  shared  memory  array  without  signalling  the  send 
process  to  send  it  until  the  entire  block  was  ready.  Such  a  solution  eliminates  any  need  to 
change  the  receiving  functions  at  the  cost  of  either  an  additional  sending  function  or  an 
additional  parameter  to  the  existing  send  functions.  The  additional  send  function  would 
be  a  push  function  and  the  existing  send  functions  would  be  modified  to  never  signal  the 
send  process  to  send.  That  would  be  left  to  the  new  push  function.  Adding  a  parameter 
to  each  send  function  would  allow  any  send  function  to  push.  While  in  some  respects 
simpler,  changes  to  any  application  sending  a  block  of  data  would  have  to  carefully 
monitor  which  send  function  actually  is  pushing. 

Creation  of  a  Lisp  flavor  that  mimics  the  UNIX  functions  would  prove  useful  to  C 
programmers  who  find  a  need  for  Lisp  modules  in  their  Visual  simulation.  Adding  server 
and  broadcast  capabilities  would  increase  the  applicability  of  the  protocols  to  future 
visual  simulation  projects.  Functions  to  break  complex  Lisp  objects  into  simple  ones  and 
then  combine  these  into  a  single  message  are  necessary  for  the  broadcast  protocol.  The 
Symbolics  version  should  be  corrected  to  send  a  packet  only  at  message  boundaries. 

C.  SUMMARY  AND  CONCLUSION 

The  routines  described  herein  have  already  proved  useful  to  researchers  at  the  Naval 
Postgraduate  School.  With  Ethernet  loading  never  exceeding  one  percent,  these  routines 
are  efficient  enough  to  use  without  concern.  With  the  additions  mentioned  above,  the 
goal  of  an  easy-to-use  yet  powerful  system  will  be  reached. 


APPENDIX  A  -  IRIS  MODULE  DESCRIPTIONS 


i.  number  received 

number_rece ived(  instructure  ) 

Machine  * i ns t r uc t u re ;  /*  includes 

char  *  ins t rue t ure . segment  a  pointer  to  the  shared  segment 
*/ 

ii.  read  character 

read_char ac  t e  r ( instructure, charact e  r_ou  t ) 

Machine  * i ns t rue ture ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment  */ 
char  ‘charac ter_out ;  I*  pointer  to  output  character  */ 

iii.  read  characters 

read_charac  t e  r s ( i ns  tructure.outarray, array size) 

Machine  * i ns t rue ture ;  /*  includes 

char  * i ns t rue tu re . segment  a  pointer  to  the  shared  segment  */ 
char  outarray[];  /*  output  character  buffer  */ 
int  arraysize;  /*  the  number  of  characters  to  be  returned  */ 

iv.  read Jioat 

read_f!oat( instructure, float _out ) 

Machine  * i ns t rue t u re ;  /*  includes 

char  *  i  ns t rue t ure . segmen t  a  pointer  to  the  shared  segment  */ 
float  *float_out;  /*  pointer  to  output  float  */ 

v.  read  integer 

r  e  ad_ i n  t  e  ge  r (  in structure, integer _out ) 

Machine  ‘instruct ure,  /*  includes 

char  *  i ns t rue ture . segmen t  a  pointer  to  the  shared  segment  */ 
int  * i n t ege r_ou t ;  /*  pointer  to  output  integer  */ 
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vi.  receivedjype 

char  rece i ved_type(  instructure  ) 

Machine  *  i ns t rue t u re ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment 
*/ 

vii.  write ^character 

wr  i te_charac  ter(instructure,character_in) 

Machine  *  ins t rue t ure ;  /*  includes 

char  *ins tructure . segment  a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem  the  semaphore  to  the  sender  */ 
char  *charac ter_in ;  /*  pointer  to  input  character  */ 

viii.  write  characters 

write _characters(instructure,inarray,arraysize) 

Machine  * i ns t rue ture ;  /*  includes 

char  *  i  ns t rue t ure . s egmen t  a  pointer  to  the  shared  segment 

int  ins t rue ture . rece i vesem  the  semaphore  to  the  receiver, 
char  *inarray;  /*  input  character  buffer  */ 
long  arraysize;  /*  the  number  of  characters  input  */ 

ix.  write Jioat 

write_float( instructure, float_in) 

Machine  * i ns t rue t u re ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem  the  semaphore  to  the  sender  */ 
float  *float_in;  /*  pointer  to  input  float  */ 

x.  write  integer 

wr  it e_integer(i ns tructure, integer_in) 

Machine  * i ns t rue t ure ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment 
int  ins t ructure . sendsem  the  semaphore  to  the  sender  */ 
int  *integer_in;  /*  pointer  to  input  integer  */ 


65 


io_sing!e.c 


^include  "shared. h" 

#i nc i ude  "g 1 . h" 

/*  The  following  routine  copies  a  character  into  the  shared  segment. 

It  puts  the  type  CHARACTER_TYPE  in  the  first  byte  and  the 
length  OOOl  into  the  next  four  bytes. 

It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 

*/ 

write _character(instructure,character_in) 

Machine  * i n s t rue t u re ;  /*  includes 

char  *  ins t rue ture . segmen t  a  pointer  to  the  shared  segment 
int  i n s t rue t ure . s endsem  the  semaphore  to  the  sender  */ 
char  *cha  r  ac  t  e  r_i n ;  /*  pointer  to  input  character  */ 


int  msgsize  =  5  +  CHARACTERS  I ZE ;  /♦  size  of  message  */ 

char  * sende r start  =  i ns t rue t u r e - >s e gmen t  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  ♦sentlength  ■  (long  * ) i n s t r uc t u re ->segmen t  +  WSEN3EROFFSET; 

/*  insert  the  type  code  */ 

♦(senderstart  +  4)  =  CHARACTER_TYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
sp r i n t f ( ( sende r s t a r t  +  5),  "%04d"  ,  CHARACTER_SIZE) ; 

/*  move  the  data  bytes  */ 

memepy ( da t a s t a r t ,  cha r ac t e r_ i n ,  CHARACTER_SI3i) ; 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
♦sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*/ 

V(  instructure ->s endsem)  ; 


1  /*  wr i t e_cha r ac t e r  */ 
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/*  The  following  routine  converts  an  integer  to  a  string  and  copies  it 
into  the  shared  segment. 

It  puts  the  type  INTEGER_TYPE  in  the  first  byte  and  the  string  length 
(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 

*/ 

write_integer( instructure, integer_in) 

Machine  *  ins t rue t ure  ;  /*  includes 

char  *  ins t rue t ure . segmen t  a  pointer  to  the  shared  segment 
int  i ns t rue t ure . sendsem  the  semaphore  to  the  sender  */ 
int  *integer_in;  /*  pointer  to  input  integer  */ 

I 

char  in t ege r_s t r ing [20] ;  /*  string  for  integer  conversion  */ 

int  length;  /*  length  of  integer  string  */ 

intmsgsize;  /*  size  of  message  ♦/ 

char  ’senderstart  =>  i n s t rue t u re ->s egmen t  +  SEMDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  *sentlength  =  (long  * ) i ns t rue t ure ->segmen t  +  WSEtOEROFFSET; 

/*  convert  integer  to  string  */ 

sprint f(  i n t ege r_s t r ing , "%dv ,  *intcger_in  ); 

/*  find  length  of  integer  string  and  thus  message  */ 
length  =>  strlen(  i  n  t  ege  r_s  t  r  i  ng  ); 
msgsize  =  5  +  length; 

/♦  insert  the  type  code  */ 

♦(senderstart  +  4)  =  INTEGER_TYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
spr i n t f ( ( sende r s t ar t  +  5),  "%04d"  ,  length); 

/*  move  the  data  bytes  */ 

memepy ( da t as t a r t  ,  i n t ege r_s t r i ng  ,  length); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  ♦/ 

♦sent  length  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  se  gme  n  t  . 

*/ 

V( instructure  - >s  endsem)  ; 

|  /*write_integer  */ 
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/*  The  following  routine  converts  a  float  to  a  string  and  copies  it 
into  the  shared  se gme n t  . 


:  d  s  e  bit 

It  puts  the  type  FLOAT_TYPE  in  the  first  byte  and  the  length 

(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 


write_float( instructure, float_in) 
Machine  * i n s t r uc t u re  ;  /*  includes 


char  *instructure. segment  a  pointer  to  the  shared  segment 


int  instructure. sends  em 


the  semaphore  to  the  sender  */ 


float  *float_in;  /*  pointer  to  input  float  */ 


char  f  1  oa t _s t r i ng [ 30 J ;  /*  string  for  float  conversion  */ 


int  length; 
int  msgs  i  ze ; 


/*  length  of  float  string  */ 
/  *  size  of  me  s  s  a  g  e  * / 


char  *senderstart  =  i n s t rue t u re - >s egmen t  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  ’sentlength  =  (long  *  )  i ns t rue t ure ->segmen t  +  WSENDEROFFSET; 

/*  convert  float  to  string  */ 

sprintff  f 1 oa t _s t r i ng ,  "%{"  ,  *float_in  ); 

/*  find  length  of  float  string  and  thus  message  */ 
length  =  strlen(  float_string  ); 
msgsize  =  5  +  length; 

/*  insert  the  type  code  */ 

•(senderstart  +  4)  =  FLQAT_TYPE; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
sp r i n t f ( ( s ende r s t a r t  +  5),  ”%04d"  ,  length); 

/•  move  the  data  bytes  •/ 

memepy ( da t a s t a r t ,  f I oat_s t r i ng ,  length); 

/•  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
•sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*1 

V(  instructure->sends em )  ; 


1  /*write_f!oat  •/ 


io_single.c 

/*  This  routine  returns  the  number  of  data  items  received.  * / 
n  umb  er_received(  instructure  ) 

Machine  *inst  ructure;  /*  includes 

char  *ins  t  ructure  .  segment  a  pointer  to  the  shared  segment  */ 

( 

i n  t  t  emp_ i n  t ; 

char  ‘protocolhold  =  i n s t rue t u r e ->s e gmen t  +  PROTOCOLHOLDOFFSET ; 
long  *par  t  received  =  (long  * ) p r o t oco 1  ho  1 d ; 

long  * rece i ved 1  eng t h  =  (long  * ) i n s t r uc t u re ->s egmen t  +  WRECEIVEROFFSET; 

char  ‘receiverstart  =  i n s t rue t u r e ->s e gmen t  +  RECEIVHIOFFSET; 

/*  check  if  only  part  of  protocol  information  received  */ 

if(  * rece i ved 1  eng t h  <  5) 

I 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memc  py(  protocolhold,  receiverstart,  ‘receivedlength  +  4  ); 

/*  get  next  message(s)  */ 
f  ree_recei ver( ins  t  ructure->se  gme  n  t ) ; 

V(  instructure->receives  em)  : 

wh  i  1  e (  r ec e i ve r_ i s_f ree ( i n s t rue t u r e ->se gmen t )  )  /*  wait  */  ; 

/*  copy  rest  of  protocol  data  into  holding  area  */ 

memcpy(  (protocolhold  +  *pa r t rece i ved  +  4),  (receiverstart  +  4), 

(5  -  *pa r t r ec e i ved )  ); 

) 

else 

1 

/*  copy  protocol  data  into  holding  area  */ 
memcpy(  protocolhold,  receiverstart,  9); 

/*  initialize  ‘par t rece i ved  so  it  can  be  used  later  */ 

*pa  r  t  r ec  e i ved  =  0; 


/*  determine  the  length  of  the  received  integer  string  and  thus  message  */ 
sscanf(  protocolhold  +  5,  "%d",  &temp_int  ); 

switch)  * ( p r o t oco 1  ho  1 d  +  4)  ) 

I 

case  CHARACTER  _  F/PE : 
re  t  u  rn(  1  )  ; 
break. 

case  1  NTEGER_TYPE : 
return!  1  )  ; 

break; 

case  FLOATTYPE : 
return!  1  )  ; 

break; 

case  CHARACTER_ARRAY_7 YPE  : 

return!  t  etnp_  i  n  t  /CHARACl  bR_S  IZE  ); 
break  ; 

case  1 NTEG  ER_ARRA Y_TYP  E  : 

return!  t emp_ i n t / INTEGER_S IZE  ); 
break; 

case  FLOAT_ARRAY_TYPE : 

return)  t  emp_  i  n  t  /  FLOAT_S  I  7.E  )  ; 

I 

|  /*  numbe rrece i ved  */ 
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/*  The  following  routine  returns  a  character  from  the  shared  segment. 
It  fr'es  the  receiver  side  of  the  shared  segment  if  it  is  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 


read_character( inst  ructure .charac  ter_out ) 

Machine  * i ns t r uc t u r e ;  /*  includes 

char  * i n s t rue t u re . segmen t  a  pointer  to  the  shared  segment  */ 
char  *cha r ac t e r_ou t ;  /*  pointer  to  output  character  */ 


/*  temporary  storage  for  move  of  received  data  or  for  protocol  information 
when  partial  receipt  *  / 
char  t  enip  [  LARGESTREAD  ]  ; 


char  *protocolhold  =  ins t rue ture ->segmen t  +  PROTOOOLHOLDOFFSET ; 


/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *pa r t r ec e i ved  =  (long  * )pro t ocol ho  1 d; 


i  n  t  ms  g  s  i  ze 


=  5  +  CHARACI tR_S I ZE ;  /*  size  of  message  * / 


char  * r ece i ve r s t a r t  =  i n s t rue t u re -> segmen t  +  RECE1VEROFFSET; 


/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  ’datastart  =  receiverstart  +  9; 


long  *recei vedlength  =  (long  * ) i n s t rue t u re - >s egmen t  +  WRECEIVEROFFSET; 

/*  check  if  first  part  of  protocol  information  is  missing  */ 
if(  *pa r t rece i ved  ==  0  ) 

I 

/*  check  if  only  part  of  protocol  information  received  */ 
if(  ’receivedlength  <=  5) 

( 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memepy(  p ro t oco 1  ho  1 d ,  receiverstart,  * rece i ved 1  eng t h  +  4  ); 

/*  get  next  message's)  */ 
free_receiver(instructure - >s  egmen  t ) ; 

V(  inst  ructure->receive  sent)  ; 

while(  r ece i ve r_i s_f r ee ( i n s t r uc t u r e ->se gmen t  )  )  /*  wait  */  ; 

I 

} 

/*  reset  msgsize  and  data  start  to  correspond  to  partial  receipt  */ 
msgsize  -=  *pa r t r ec e i ved ; 
datastart  -=  *partreceived; 

I*  move  the  bytes  */ 

mcmc py ( c h a r ac t e r_ou t ,  datastart.  CHARACTER_S f ZE ) ; 

/*  make  buffer  ready  for  next  read  */ 

resetbuffert  receivedlength,  msgsize,  instructure,  datastart, 

CHARAC 1ER_S I ZE ,  part  received  ,  receiverstart  ); 


I  /  *  read_character  * / 
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/*  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  returned  integer. 

It  frees  the  receiver  side  of  the  shared  sc  gme  n  t  if  it  is  emp  t  y . 
It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 

*  / 


read_integer( instructure, integer_out) 

Machine  *  ins t rue t ure  ;  /*  includes 

char  *  ins t rue t ure . segmen t  a  pointer  to  the  shared  segment  */ 

int  ‘integer  out;  /*  pointer  to  output  integer  *1 

1 


char  i n t ege r_s t r i ng [LARGESTREAD] ;  /*  string  storage  for  received  data 

char  *p ro  t  oco  1  ho  1  d  =  ins  t  rue  ture ->segmen  t  +  PROTOCX5IJCIJDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  * / 
long  *pa r t r ece i ved  =  (long  *  )  p ro t oc o 1  ho  1 d ; 


int  length; 

long  segmen t 1  eng t h ; 

int  ms g s i ze ; 

char  * r ec e  i  ve r s t a r t 


/*  length  of  integer  string  read  */ 
/*  length  of  data  of  partial  massage 
/*  size  of  message  */ 
i  ns  1  r uc t u r e - > s egmen t  +  RECEIVEROFFSET; 


/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  "datastart  =  r ec e  i  ve r s t a r t  +  9; 
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/ 


long  "receivedlength  =  (long  * ) i n s t rue t ure - >segmen t  +  VnRECEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t _p ro t oco 1 (  p ro t oco 1  ho  1 d ,  pa r t rece i ved ,  rece i ved I  eng t h ,  r ece  i  ve r s t a r t  , 
instructure,  &length,  cSmsgsize,  &datastart  ); 

/*  check  if  only  part  of  data  has  been  received  */ 

if(  * rece i ved I  eng t h  <  msgsize  ) 

{ 

get_data(  &s  egmen t I  eng t h ,  rec e i ved 1  eng t h ,  pa r t rece i ved , 
i  n  t  ege  r_s  t  r  i  ng  ,  &datastart,  <&msgsize, 
r ece  i  ve r s t a r t  ,  instructure,  &length); 

/*  convert  to  string  */ 

i n t ege r_ s t r i ng [ s egmen t 1  eng t h  +  msgsize]  =  ’\0’; 

I 

else 

I 

/*  move  the  integer  string  bytes  ♦/ 
ntemepy ( i n t ege r_ s t r i ng  ,  datastart,  length): 

/ *  convert  to  string  * / 
i  n  t  ege  r_s  t  r  i  ng  [  I  engt  h  ]  =  '  \<) '  ; 


/*  convert  the  received  string  to  an  integer  */ 
s sc  an  ft  i  n t ege r_s t r i ng ,  "%d" ,  integer_out  ): 

/*  make  buffer  ready  for  next  read  */ 

reset  buffert  receivedlength.  msgsize,  in  structure,  datastart,  length, 
partreceived,  receiver  start  ); 

|  /  *  read_integer  * / 
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/*  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  user  supplied  float. 

It  frees  the  receiver  side  of  the  shared  segment  if  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 

*  / 

read_float( inst  ructure, float_out  ) 

Machine  *ins  t  ructure;  /*  includes 

char  * i n s t rue t u re . segmen t  a  pointer  to  the  shared  segment  */ 
float  *float_out;  /*  pointer  to  output  float  */ 

I 

char  f loa t _s t r i ng [LARGESTREAD] ;  /*  string  storage  for  received  data  */ 

char  *protocolhold  =  i n s t rue t u r e ->s egmen t  +  PROTDCOLHOLJDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *pa r t rece i ved  =  (long  * ) p r o t oco Iho 1 d ; 

int  length;  /  *  lengthof  float  string  read*/ 

long  segmen t 1  eng t h ;  /*  length  of  data  of  partial  massage  */ 

intmsgsize;  /*  size  of  mesnge  */ 

char  * r ece  i  ve r s t a r f  =  i n s t rue t u re ->s egmen t  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  ‘datastart  =  rece  i  ve r s t ar t  +  9; 

long  *recei vedlength  =  (long  * ) i ns t rue t u re - >s egmen t  +  YiRECEIVEROFFSET; 


/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t _pro t oco 1 (  protocolhold,  pa r  t  r ece i  ved ,  r ece i-vedl eng t h  ,  rec e i  ve r  s  t  a r  t  , 
instructure,  &length,  (Smsgsize,  Adatastart  ); 

/*  check  if  only  part  of  data  has  been  received  */ 
if(  *recei vedlength  <msgsize  ) 

( 

get_data(  As egmen t 1  eng t h ,  r ece i ved 1  eng t h ,  pa r t rece i ved , 
f 1 oa t_s t r i ng ,  Adatastart,  Ansgsize, 
rece i ve r s t a r t ,  instructure,  Alength); 

/ *  convert  to  string  */ 

f loa t  s t r i ng [ segmen t lengt h  +  msgsize]  =  ’\0'; 

) 

else 

I 

/*  move  the  float  string  bytes  */ 

memc  py(float_string,  datastart,  length); 

/*  convert  to  string  */ 
f  l  oa t _s t r i ng [ 1  eng t h]  =  '\0‘; 


/*  convert  the  received  string  to  an  float  */ 
sscanft  float_string,  “%{"  ,  float_out  ); 

/*  make  buffer  ready  for  next  read  */ 

reset_buffer(  receivedlength.  msgsize,  in  structure,  datastart,  length, 
partreceived,  receiverstart  ); 

I  /*  read  float  */ 
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/*  The  following  routine  copies  characters  from  an  array 
into  the  shared  segment. 

It  puts  the  type  CHARACTER_ARRAY_TYPE  in  the  first  byte  and  the 
array  length  (in  bytes)  as  an  integer  into  the  next  four  bytes. 

It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  progr am 

*/ 

write_characters(instructure,inarray,arraysize) 

Machine  *  in s t r uc t u r e  ;  /*  includes 

char  *  i  n s t rue t u r e . segmen t  a  pointer  to  the  shared  segment 
int  i n s t rue t u r e . rec e i ve s em  the  semaphore  to  the  receiver, 
char  *inarray;  /*  input  character  buffer  */ 
long  arraysize;  /*  the  number  of  characters  input  */ 

I 

int  datasize  =  arraysize  *  CHARAC I'ER_S I ZE ;  /•  size  of  data  field  */ 

int  msgsize  =  5  +  datasize;  /*  size  of  message  */ 

char  ’senderstart  =  i ns t rue t u r e - >segmen t  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  *sentlength  =  (long  * ) i ns t rue t ur e ->segmen t  +  WSEN5EROFFSET; 

/*  insert  the  type  code  */ 

•(senderstart  +  4)  =  CHARACTERARRAY^TYPE ; 

/•  insert  the  length  IN  BYTES  of  the  input  data  */ 
spr i n t f ( ( sende r s t ar t  +  5),  "%04d" ,  ( i n t ) da t as i ze ) ; 

/*  move  the  data  bytes  •/ 

memepy ( ( da t a s t a r t  )  ,  inarray,  datasize); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  •/ 
•sentlength  =  5  +  datasize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  se  gnte  n  t  . 

*  / 

V (  i n  s  t  r  u  c  t  u  r  e - >  s  e  n  d  s  em) ; 

)  /*  wr i t e_c ha r ac t e r s  */ 
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/*  The  following  routine  copies  bytes  from  the  shared  segment 
into  the  user  supplied  array. 

It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 

*/ 

read_characters( instructure, outarray, arraysize) 

Machine  *  ins t rue ture ;  /*  includes 

char  *  i  n s t rue t ur e  .  s egmen t  a  pointer  to  the  shared  segment  */ 
char  outarray[] ;  /*  output  character  buffer  */ 

int  arraysize;  /*  the  number  of  characters  to  be  returned  */ 

( 

char  *pr o t  oco  1  ho  1  d  =  ins  t  rue  ture ->segmen  t  +  PROTOCOLHOLDOFFSETT ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *par t rece i ved  =  (long  *  )  p ro t oco 1  ho  I d ; 

int  length:  /*  length  of  character  string  read  */ 

long  s egmen t I  eng t h ;  /*  length  of  data  of  partial  massage  */ 

int  datasize  =  arraysize  *  CHARACTER_S IZE ;  /*  size  of  requested  data  field 

int  requestsize;  /*  size  of  message  */ 

int  msgsize  =  5  +  datasize;  /*  size  of  requested  message  */ 

char  * rece i  ve r s t ar t  =  i ns t rue t ure ->segmen t  +  RECEIVEROFFSET; 

/*  the  t  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  »  rece i ve r s t ar t  +  9; 

long  *receivedlength  =  (long  *) i n s t rue t ure - >s egmen t  +  WRECEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t _pro t oco 1 (  pro t oco 1  ho  1 d ,  pa r t r ece i ved ,  rece i vedl engt h .  rece i ve r s l a r t  , 
instructure,  &length,  fimsgsize,  &datastart  ); 

/*  check  if  all  of  data  (or  more)  was  requested  */ 

if(  length  <=  arraysize  ) 

I 

I*  check  if  only  part  of  data  has  been  received  */ 
if(  *receivedlength  <  msgsize  ) 

I 

get_data(  &s egmen t 1 e ng t h ,  receivedlength,  part  received, 
out  array,  &da  last  art,  <&msgsize, 
receiverstart,  in  structure,  &d  a  t  a  s i z  e  ) ; 

1 

else 

I 

!*  move  the  character  bytes  */ 
memepy ( ou t a r r ay  ,  datastart,  length); 

I 


/*  make  buffer  ready  for  next  read  */ 

rese t_buf fer(  receivedlength,  msgsize.  instructure,  datastart,  datasize 
pa r t rece i ved ,  receiverstart  ); 
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/*  These  are  various  support  routines  used  by  several  of  the  preceding 
f  unc  t  i  on  s  . 

*/ 

r e se t _bu f f e r ( rece i ved I  eng t h ,  msgsize,  instructure,  datastart,  dalasize, 
partreceived,  receiverstart) 

long  * r ece i ved I  eng t h ;  /*  first  four  bytes  of  receive  part  of  shared  seg  */ 

int  msgsize;  /*  size  of  message  read  */ 

Machine  *  i  n s t r uc t u re  ;  /*  includes 

char  *  ins t rue t ure . segmen t  a  pointer  to  the  shared  segment 
int  i n s t rue t u r e . r ece i ve s em  the  semaphore  to  the  receiver.  */ 
char  ’datastart;  /*  address  data  starts  in  receive  part  of  shared  seg  */ 

int  datasize;  /*  length  of  data  part  of  message  */ 

long  *pa r t rece i ved ;  /*  length  of  message  received  in  previous  block  */ 

char  ’receiverstart ;  /*  address  receive  part  of  shared  seg  starts  */ 

( 

char  t emp [LARGESTREAD] ;  /•  temporary  storage  for  move  of  received  data  */ 

/*  free  the  receiver  segment  if  this  is  only  message  received  */ 
if(*receivedlength  ==  msgsize) 

I 

free_receiver( instruc  t ure ->segmen  t ) ; 

/*  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*/ 

V(  inst  ructure  -  >r  ece  i  ve  setn)  ; 

1 

else  /*  shift  data  forward  in  shared  memory  segment  */ 

I 

*receivedlength  -=  msgsize; 

memc p y ( t emp ,  (datastart  +  datasize),  (LARGESTREAD  -  msgsize)); 
memcpy( ( receiverstart  +  4),  temp,  (LARGESTREAD  -  msgsize)); 

I 

/*  reset  ’partreceived  for  next  read  */ 

’partreceived  =  0; 

|  /*  reset  buffer  */ 
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ge t _p r o t oco 1 (  p ro t oco l ho  I d ,  partreceived,  r ec e i ved 1 e ng t h ,  receiverstart  , 
instructure,  length,  msgsize,  datastart  ) 

cliar  ’protocol  hold;  /  *  protocol  holding  area  *  / 

long  *pa r t r ec e  i  ved ;  /*  length  of  message  received  in  previous  block  */ 

long  * rece i ved 1  eng th ;  /*  first  four  bytes  of  receive  part  of  shared  seg  */ 

char  ’receiverstart;  /*  address  receive  part  of  shared  seg  starts  */ 
Machine  *  i  n s t rue t u r e ;  /*  includes 

char  ’instructure. segment  a  pointer  to  the  shared  segment 
int  instructure.receivesem  the  semaphore  to  the  receiver.  */ 
int  ’length;  /*  length  of  data  field  in  message  */ 


int  *  I  eng  t h ; 
int  ’msgsize; 
char  ”da  t  as  t  a r  t  ; 


/  *  length  of  me  s  s  a  g  e  * / 

/*  address  data  starts  in  receive  part  of  shared  seg  */ 


/*  check  if  first  part  of  protocol  information  is  missing  */ 
if(  ’part  received  ==  0  ) 

I 

/’  check  if  only  part  of  protocol  information  received  */ 
iff  * r ece i ved l eng t h  <=  5) 

I 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memepyf  p ro t oco 1  ho  1 d ,  receiverstart,  ’ rec e i ved 1  eng t h  +  4  ); 

/*  get  next  message(s)  */ 
free_receiver(instruc  t  u re ->segmen t ) ; 

V( inst  ructure->receivesem) ; 

whilef  receiver_i s_f reef  ins t rue t u re ->s egmen t )  )  /*  wait  ’/  ; 

/♦  copy  rest  of  protocol  data  into  holding  area  */ 

memepyf  ( p ro t oco 1  ho  1 d  +  *pa r t rece i ved  +  4),  (receiverstart  +  4), 

(5  -  ’par t rece i ved)  ); 

I 

else 

( 

/*  copy  protocol  data  into  holding  area  */ 
memepyf  p ro t oco 1  ho  1 d ,  receiverstart,  9); 

/*  initialize  ’par t rece ived  so  it  can  be  used  later  */ 
’partreceived  =  0; 


/*  determine  the  length  of  the  received  data  string  and  thus 
sscanft  protocolhold  +  5,  "%d" ,  length  >: 

’msgsize  =  5  +  ’length  -  ’partreceived; 


me  s  s  a  g  e  * / 


"msgsize  =  5  +  ’length  -  ’partreceived; 

I  ’  reset  datastart  to  c  omp  ensate  for  pos 
"datastart  -=  ’partreceived: 

/  *  get_protocol  */ 


possible  partial  receipt  ’/ 


$ 

& 


I 


.  •-  /.  'J.  V  *  -  * 
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get_data(  s egmen t I  eng t h ,  rece i ved I  eng t h ,  pa r t rece i ved ,  s t r i ng_a r r ay , 
datastart.  msgsize,  rece i ve r s t a r t ,  instructure,  datasize  ) 

long  * s egnien t 1  eng t h :  /*  length  of  partial  data  */ 

long  ‘receivedlength;  /*  first  four  bytes  of  receive  part  of  shared  seg  */ 
long  *pa r t r ec e i ved ;  /*  length  of  message  received  in  previous  block  */ 


char  s t r i ng_a r r ay ( ] 
char  **da  t  as  t  a r  t  : 
i n  t  *ms  g  s  i  z  e ; 
char  ‘receivers  tart 


/  *  storage  for  incoming  characters  ‘  / 

/  *  address  data  starts  in  receive  part  of  shared  seg 
/*  length  of  message  */ 

/*  address  receive  part  of  shared  seg  starts  */ 


Machine  *  ins t rue t ure ;  /*  includes 


char  * i n s t rue t ure . s egmen t  a  pointer  to  the  shared  segment 


int  inst  ructure. receivesem  the  semaphore  to  the  receiver. 


int  *datasize; 


/*  length  of  data  field  in  message  */ 


/*  determine  length  of  data  that  has  been  received  */ 

* s egmen t 1  eng t h  =  * r ec e i ved I  eng t h  -  5  +  *pa r t r ece i ved ; 

/*  copy  the  first  segment  of  data  to  holding  array  */ 
memepyf  s t r i ng_a r ray  ,  ‘datastart  ,  * s egmen t  1  eng t h  ); 

/*  reset  msgsize  and  datastart  to  correspond  to  partial  receipt  */ 
‘msgsize  -=  * s egmen t 1  eng t h  +  5  -  *pa r t rece i ved ; 

‘datastart  =  rece i ve r s t ar t  +  4; 

/*  get  next  message(s)  */ 
free_receiver( instruc  t ur e ->s egmen t ) ; 

V(  instruc  t u r e ->r ece i ve sem) ; 

wh i 1 e (  rece i ve r_i s_f ree ( ins t rue t ure ->segmen t )  )  /*  wait  */  ; 

/*  cycle  through  as  many  messages  as  it  takes  */ 
wh i 1 e (  ‘receivedlength  <  ‘msgsize  ) 

I 

/*  copy  the  next  segment  of  data  to  holding  array  */ 

memepyf  &s  t r i ng_a r r ay [ * segmen t 1  eng t h J ,  ‘datastart,  ‘receivedlength  ); 

/*  reset  msgsize  and  s egmen t I  eng t h  to  correspond  to  partial  receipt  * 
‘msgsize  -=  ‘receivedlength; 

* segmen t I  eng t h  -=  ‘receivedlength; 

/*  get  next  message(s)  */ 
f  ree_receiver( inst  ructure->se  gmen  t  )  ; 

V ( inst  ructure->receivesem) ; 

while(  r ece i ve r_ i s _f r ee ( i n s t rue ' u r e -> se gmen t )  )  /*  wait  */  ; 

I 

/*  copy  the  last  segment  of  data  to  holding  array  */ 
memepyt  &s t r i ng_a r r ay [ * s e gmen t 1  eng t h | .  ‘datastart.  ‘msgsize  ); 

/*  reset  datasize  to  properly  reflect  last  se  gme  n  t  size  *  / 

‘datasize  =  ‘msgsize; 

1  /  *  ge  t _d a  t  a  * / 


2.  mpath.c 

a.  Calling  Protocols 

All  functions  in  this  module  are  meant  to  be  accessible  by  the  application. 
These  functions  set  up  and  tear  down  the  communications  path  between  two  machines. 

i.  deletemachinepath 

de  l  e  t  emach  i  nepa  th(instructure) 

Machine  ‘instructure;  /*  structure  to  hold  segment  and  semaphore  info: 

char  ‘instructure. segment  --  returned  ptr  to  the  shared  segment, 
int  ins t rue ture . shrnid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 
int  in s t rue t u re . rece i ve sem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 

*1 

ii.  machinepath 

mach i nepa  t  h ( s  egmen  t  num.mname  , sendport  num,  rece iveportnum, server . inst  ructure  ) 

long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname  [ ] ;  /*  machinename  character  string  */ 

long  sendpor t num,  rece ivepor tnum;  /*  send  and  receive  port  numbers  */ 
char  server(J;  /*  this  character  string  is  either  "client"  or  "server". 

It  indicates  whether  the  sende r / rece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
mus  t  be  the  server. 

*/ 

Machine  * i n s t rue t u re ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . s egmen t  --  returned  ptr  to  the  shared  segment, 
int  i n s t rue t u re . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 
int  i n s t rue t u r e . r ece i ve s em  --  the  returned  receive  semaphore. 

*/ 

iii.  dynamicmachinepath 

dyn  ami  cmach i nepa  t  h ( s egmen  t  num.mname .sendport  num,  receiveport  num,  server , 
in  structure, freespace) 

long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mnamef];  /*  machinename  character  string  */ 

long  sendpo r t num, rece i vepo r t num;  /*  send  and  receive  port  numbers  */ 
char  server]];  /  *  this  character  string  is  either  "client"  or  "server", 

It  indicates  wh ether  the  sender/receiver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server. 

*/ 

Machine  *inst  ructure;  /*  structure  to  hold  segment  and  semaphore  info: 

char  ‘instructure.se gme  lit  --  returned  ptr  to  the  shared  se  gme  n  t 
int  i n s t rue t u re . shmi d  --  returned  system  generated  shared  mem  id 
int  i n s t r uc t u r e . s end sem  --  the  returned  send  semaphore 

We  base  it  on  the  send  portn  limb  e  r 
int  ins t rue t u re . rece i ve sem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portn  umb  c  r 

*/ 

int  freespace;  /*  amount  of  freespace  desired  for  dynamic  memory  allocation 
after  this  routine  has  been  called.  *  / 


CWH! 


iv.  dynamicmachinepaths 

dy  n  ami  cmach  i  nepa  t  It  s  (  nurrmach  i  ne  s  ,  segmen  t  num.mname  ,  s  endpo  r  t  num.  receiveporl  nuni, 
server, instructure, freespace) 

int  numtiachines:  /*  the  maximum  number  of  other  machines  to  be  attached  */ 

long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname[J;  /*  machinename  character  string  */ 

tong  sendpor I num,  rece i vepor t num;  /*  send  and  receive  port  numbers  */ 
char  server!];  /*  this  character  string  is  either  "client"  or  "server". 

It  indicates  whether  the  s ende r / rece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
mus  t  be  the  server. 

*/ 

Machine  *inst  ructure;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  i  n s t rue t u r e . s egmen t  --  returned  ptr  to  the  shared  segment, 
int  i  n s t r uc t u r e . shmi  d  --  returned  system  generated  shared  mem  id 
int  i n s t r uc t u r e . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 
int  instructure. receives em  --  the  returned  receive  s emn p h o r e  . 

We  base  it  on  the  receive  portnumber 

*/ 

int  freespace;  /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 
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#include  "shared. h"  /*  my  special  defines  */ 
# i nc 1 ude  <g 1 . h> 

de  1  e  t  eniach  i  nepa  t  h  (  inst  rue  ture  ) 


Ma  chine 


* i n structure;  /*  structure  to  hold  segment  and  semaphore  info: 

char  * i n s t r uc t u r e . segmen t  --  returned  ptr  to  the  shared  segment. 

int  i n s t r uc t ur e . s hmi d  --  returned  system  generated  shared  mem  id 

int  instructure. sends  em  --  the  returned  send  s  ema  p  h o  r  e . 

We  base  it  on  the  send  portnumber. 

int  instructure. receives  em  --  the  returned  receive  s  ema  p  h  o  r  e  . 

We  base  it  on  the  receive  portnunibe 


*/ 


t*  kill  the  receiver  process  . .  */ 

ki 1 l_receiver( instructure->se  gmen  t ,instructure->receive  sem)  ; 
/*  kill  the  sender  process  */ 

ki I l_sender( instructure->se  gme  nt  ,instructure->sends  em )  , 

/*  detach  and  delete  the  shared  segment  . .  */ 

de 1 e  t  e  s  ha  r  eds  egmen t(instructure->se  gmen  t  , instructure ->s  hmi  d ) ; 


in  trv  w  vrT'vv.  vw'^totj,' 
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For  airect  connection,  both  send  and  receive  processes  are  spawned. 

For  broadcast,  either  send  or  receive  process  is  spawned. 

The  niachinepath  routine  performs  the  following: 

(1)  creates  a  shared  se  gme  n  t . 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
po  r  t  numbe  r  s . 

(3)  f ree_sende r ( se  gmen t )  and/or  f r ee_r ec e i ve r ( s egmen t ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

sy s t em(  " send  s ha redseg#  mach i nename  port#  se r ve r /c 1 i en t /b roadc a s t  0&"  ) : 
system!  "receive  sharedseg#  machinename  port#  server/c 1 ient/receive  0&" )  : 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

*/ 

much i ne pa  t  h ( segmen  t  num.mname , sendport  num, receiveport  num,  server, instructure) 


long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mnamef];  /*  machinename  character  string  */ 

long  sendpor t num.  r ece i vepor t num;  /*  send  and  receive  port  numbers  */ 

char  serverf];  /*  this  character  string  is  either  "client",  "server”. 

"broadcast”,  or  "receive".  If  direct  connection  wanted, 
it  indicates  whether  the  sender/receiver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.  If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 

*/ 

Machine  *  ins t rue t ure ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segmen t  --  returned  ptr  to  the  shared  segment, 
int  ins t rue t ure. shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 

int  instructure. receivesem  --  the  returned  receive  semaphore. 

*/ 

I 

char  *sharedsegment ( ) ;  /*  shared  segment  creation  function  */ 

int  semtranf);  /*  semaphore  creating  routine.  */ 

char  temp[200],  temp2[200];  /*  temp  character  arrays  */ 


/*  create  the  shared  segment  */ 

in st  ructure - >s  egnten  t  =  s  ha  r ed segmen t ( segmen  t  num.MAXSHAREDS IZE ,&i n  s  t  r uc  t  u  r e ->shmi  d ) 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
i n  s  t  r  u  c  t  u  r  e - >  s  e  n  d  s  em  =  semtran(sendportn  um )  ; 

/  *  create  the  receive  s  ema  phore  (unused  if  broadcasting  messages)  * / 
i n s t rue t u r e -> r ec e i ve s em  =  semt  ran( rece i vepor t num)  ; 

/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
ini t_shared_buffer( inst  ructure->se  gme  n  t  ) : 


/*  spawn  off  the  sender  process  */ 
i f (  strcmp(  server,  "receive"  )  1=0  ) 


85 


mpath.c 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
s  t  rc  py  (  t  enip ,  SEbDLOCATION)  ; 
s  t  r  c  a  t ( t  emp  , "  ”  )  ; 

/  *  add  the  n  umb  er  of  the  sharedse  gme  n  t  in  text  *  / 
s  p  r i n  t  f ( t  emp 2 ,  "%d" ,instructure->s  hmi d ) ; 
strcat( I emp , t  emp2 ) ; 
s  t  r  c  a  t  (  t  emp , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rc  a  t  (  t  emp  .mnarne  )  ; 
s  t  r  c  a  t  (  t emp , "  "  )  ; 

/*  add  the  port  number  */ 
spr  in  t  f  (  t  emp 2  ,  "%d"  ,  sendpor  t  nuin)  ; 
s  t  rca  t  (  t  emp ,  t  emp2 )  ; 
s  t  r  c  a  t ( t  emp , "  "  )  ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  rc  a  t ( t  emp , server) ; 
s  t  r  c  a  t ( t  emp , "  0 " ) ; 

/*  spawn  off  into  the  background  */ 
s  t  rc  a  t ( t  emp , )  ; 

/*  spawn  off  the  sender  */ 
i f (  s  y  s  t  em( t  emp )  ==  - 1  ) 

perror("SEND  system  call  failed"); 

I 

else 

( 

/*  kill  sender  (which  really  doesn't  exist  anyway)  so  that  the 
sende r_i s_f ree ( )  call  will  always  return  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  r ece i ve r_ha s_da t a  (  ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 
kill_sender(  ins t rue t u r e ->segmen t ,  ins t rue t ure ->sendsem  ); 


/*  spawn  off  the  receiver  process  */ 
iff  strcmp(  server,  "broadcast”  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
s  t  repy  (  t  emp .RECEIVELOCATION) ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  number  of  the  sh a r ed s egmen t  in  text  */ 
spr  it.  t  f  (  t  emp2  ,  "%d"  ,  inst  ructure  ->shmi  d )  ; 
s  t  rc  a  t  (  t  emp ,  t  emp2 )  ; 
s  t  r  c  a  t ( t  emp , ”  "  )  ; 

/*  add  on  the  machine  name  */ 
s  t  r  c  a  t  (  t  emp  .mnarne  )  ; 
s  t  rc  a  t (  t  emp . "  "  )  ; 

/*  add  the  port  number  */ 
sp  r i n  t  f ( t emp 2 . "%d " , recei vepor t num)  ; 
st  rc  a  t ( t  emp . t  emp2  )  ; 
s t  r  c  a  t (  t  emp , "  ” )  ; 

/ *  indicate  wh ether  a  server,  a  client,  or  a  broadcast  receiver  *  / 
s  t  r  c  a  t ( t  emp  .server); 
si  real | t  emp , "  0 " )  ; 

/*  spawn  off  into  the  background  */ 
s  t  rc  a  t (  t  emp , ) ; 
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For  direct  connection,  both  send  and  receive  processes  are  spawned. 

For  broadcast,  either  send  or  receive  process  is  spawned. 

The  dynami cmach i nepa t h  routine  performs  the  following: 

(1)  creates  a  shared  segment  and  attaches  it  to  the  main  program  virtual 
space  after  an  allocation  of  free  memory  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
po  r  t  numbe  r  s . 

(3)  f ree_sender( segment  )  and/or  f r ee_ r ece i ve r ( segmen t  ) 

(4)  spawns  off  the  send  and/or  receive  processes 

system("send  sharedseg#  machinename  port#  server/cl ient/broadcast  0&" )  ; 
sy s t em( " r ec e i ve  sharedseg#  machinename  port#  server/client/receive  0&”  ) 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  srsrmer't  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 


dynami  cmach i nepa  t h( segmen  t num.mname .sendportn urn, receiveportnum, server, 
instructure, freespace) 


long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  inn  ante  [ ]  ;  /*  machinename  character  string  */ 

long  rendpor tnum,  receiveportnum:  /*  send  and  receive  port  numbers  */ 

char  server!];  /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".  If  direct  connection  wanted, 
it  indicates  whether  the  sende r / r ece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.  If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 

*/ 

Machine  *  in s t r uc t u re  ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segmen t  --  returned  ptr  to  the  shared  segment, 
int  i ns t rue t u r e . shmi d  --  returned  system  generated  shared  mem  id 

int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 


int  i  n s t r uc t ure . r ece i ve sem 
*/ 


-  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber 


int  freespace;  /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 


char  *dynami  c sha redsegmen t (  )  ;  /*  shared  segment  creation  function  */ 

intsemtrant);  / *  s  emapho  re  creating  routine.  * / 

char  temp [200 1,  temp2[200]:  /*  temp  character  arrays  */ 


/ *  create  the  shared  s  e  gme  n  t  * / 

instructure->se  gmen  t  =  dynamiesharedse  gmen  t  (  1 . segmen  t  num  .MAXSHAREDS I ZE . 

&in structure- >s  hmi  d,  freespace  I  ; 

/  *  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  *  / 
iust  r u c  t  u  r  e - > s  e n d sem  =  s eni t  r  a n  (  sendportn um )  ; 

/  *  create  the  receive  s ema phore  (unused  if  broadcasting  messages)  *  / 
in st  ructure->receives em  =  s em Irani receiveportnum)  ; 


±UL 


/*  spawn  off  the  receiver  into  the  background  */ 
iff  s  y  s  t  em(  t  emp  )  ==  -  1  ) 

pe r ror ( "RECEIVE  system  call  failed"); 
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For  direct  connection,  both  send  and  receive  processes  are  spawned. 

For  broadcast,  either  send  or  receive  process  is  spawned. 

The  dy nami cniach i nepa t h s  routine  performs  the  following: 

(1)  creates  a  shared  segment  large  enough  for  multiple  attachments 

and  attaches  it  to  the  main  program  virtual  space  after  an  allocation 
of  free  memo r y  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
port  numbe  r  s . 

(3)  f ree_sende r 1 segmen t  )  and/or  f r e e_r ece i ve r ( segmen t  ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

system("send  sharedseg#  machinename  port#  se rve r /c 1 i en t /b roadc a s t  0&" ) ; 
sy s t em(  " rece  i  ve  sharedseg#  machinename  port#  se rve r /c 1 i en t / r ec e i ve  0&"  ) 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

*/ 

dy  nami  cmach  inepaths  (.  nummach  i  ne  s  ,  segmen  t  num.mname  ,  s  endpo  r  t  num,  receiveport  num, 
server, instructure, freespace) 

int  numaach i ne s ;  /*  the  maximum  number  of  other  machines  to  be  attached  */ 
long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname  [ ] ;  /*  machinename  character  string  */ 

long  s endpo r t num.  r ece i vepor t num;  /*  send  and  receive  port  numbers  */ 

char  serverf];  /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".  If  direct  connection  wanted, 
it  indicates  whether  the  sende r/rece i ver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.  If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 

*1 


Machine  *  i  ns t rue t u re  ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segmen t  --  returned  ptr  to  the  shared  segment. 


int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 


int  i ns t rue t u re . s ends em  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portn  umb  e  r  . 


i  n  t 


instructure. recei ve  sem 

*/ 


■-  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber 


int  freespace; 

( 


/*  amount  of  freespace  desired  for  dynamic  memory  allocation 
after  this  routine  has  been  called.  */ 


char  *dy nami  c s ha  reds e gmen t () ;  /* 
int  semtr.in():  /  * 
char  temp[200],  temp2[200];  /* 


s  t  a  t  i  c 

Boo  I 

can  first  time  =  TRUE; 

/* 

static 

i  n  t 

sequencen  um  =  0 ; 

r 

static 

i  n  t 

t  o  tmach i ne  s ; 

/* 

/*  check  for  first  time  called  and 
i  f  (  f i r  s  t  t ime  ) 


shared  segment  creation  function  */ 
semaphore  creating  routine.  */ 
temp  character  arrays  */ 
flag  to  detect  multiple  requests  */ 
sequence  number  for  receive/send  */ 
max  attachments  permitted  */ 
establish  max  possible  attachments  */ 


mmtam 
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to  (machines  =  nunniacli  i  ne  s  ; 
f i r  s  t l tme  =  FALSE: 


Iso 

+  +  sequenc  enuni; 


/*  check  for  violation  of  maximum  attachments  */ 
if(  sequencenum  >=  tolmachines  ) 


pe r r o r ( "mpa t h :  Too  many  attachments  attempted”); 
exit)  -  1  ) ; 


/  *  create  the  shared  segmen  t  * / 

i n structure ->segmen  t  =  dynamicsha  red segmen  t ( nutrmach i ne  s . segmen  t  num, 

MAXSHAREDS 1 7JE , 

&inst  ructure- >shmi  d.freespace); 


/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages) 
i  ii  s  t  rue  t  u  r  e  -  >s  end  sem  =  semt  r  an  (  s  endpo  r  t  num)  ; 
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/*  create  the  receive  semaphore  (unused  if  brondensting  messages) 
i n s t r uc t u t e - > t ec e i ve sem  =  semt  ran( rccei vepor mum)  ; 


/*  free  the  sender  and  receiver  parts  of  the  shared  segment 
ini t_shared_buffer( inst  ructure- >s egmen t ) ; 


/*  spawn  off  the  sender  process  */ 


i f (  s  t  r  emp  (  server,  "receive”  )  !=  0  ) 


I 


/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st  r  c  p y ( t  emp , SEbDLOCATION ) ; 
j  t  real  I  t  emp  , "  " ) : 


/*  add  the  number  of  the  sha r ed s egmen t  in  text  */ 
sp  r i n  t  f ( t  emp2 , "%d" , inst  ructure ->shmi  d ) : 
s  t  rca  t ( t  emp , t  emp2 ) ; 
s  t  r  c  a  t ( t  emp  , "  " ) ; 


/*  add  on  the  machine  name  */ 
s  t  r  c  a  t  (  l  emp  .inname  )  ; 
st  rcat( I emp , "  " ) ; 


/*  add  the  port  number  */ 
s  p  r i n  t  f ( t  emp  2 , "%d  " , sendportn  um )  ; 
st  real ( t emp , t  emp2 ) ; 
st  real ( I emp , "  " ) ; 


/*  indicate  whether  a  server,  a  client 
s  t  r  c  a  t ( I emp  .server); 
s  t  r  c  a  t (  t  emp  , "  " ) ; 


or  a  broadcaster  *  / 


/*  add  the  machine  sequence  number 
s  p  i  i  ii  I  f  (  t  emp  2  ,  ”%d  "  ,  sequencenum)  . 
s  I  rca  t (  t emp ,  t  emp2 ) ; 
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/*  spawn  off  into  the  background 
s  t  re  a  t ( t emp , ) ; 


7 


/*  spawn  off  the  sender  */ 
i  f  (  s  y  s  t  eni(  t  emp  1  ==  1  ) 

SEND 


per  rnrt "SEMI  system  call  failed"); 

I 

else 

I 

/  *  kill  sender  (which  r  e  a  I  I  v  doesn't  exist  a  nywa  y  )  so  that  (lie 
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sender_is_free()  call  will  always  teturn  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  r ec e  i  ve r_h a s_da t a (  ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway 
kill  sender!  ins  t  rue  ture->segment ,  i n s t rue t ure - >send sent  ): 

) 


/*  spawn  off  the  receiver  process  */ 

if!  stremp!  server,  "broadcast"  )  1=  0  ) 

( 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st  r  c  p  y  ( t  entp  ,  RECE I VELOCATION )  ; 
s  t  rcat ( temp, "  "  )  ; 

/*  add  the  number  of  the  sha r ed s egmen t  in  text  */ 
spr i n  t  f ( t  emp2 , "%d" .instruct  u  re  -  >s  hmi d ) ; 
s  t  rca  t ! t  emp , t  emp2  )  ; 
s  t  r  c  a  t ! t  emp , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t !  t  emp  .mname  )  ; 
s  t  r  c  a  t ! t  emp  , "  "  )  ; 

/*  add  the  port  number  */ 
sprintff  t emp 2 ,  "%d" , receiveport  num)  ; 
st  r  c  a  t  (  t  emp  ,  t  emp  2  )  ; 
s  t  rc  a  t ( t  emp , "  "  )  : 

/ *  indicate  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
s  t  rc  a  t ! t  emp , server)  ; 
s  t  r  c  a  t ! t  emp , "  " )  ; 

/*  add  the  machine  sequence  number  */ 
sp  r  i  n  t  f  (  t  emp 2  .  "%d"  ,  sequencenunt)  ; 
s  t  rc  a  t  !  t  emp  ,  t  emp2  )  ; 

/*  spawn  off  into  the  background  */ 
s  t  rca  t  i  t  einp  ,  )  ; 

/ ♦  s p awn  off  the  receiver  * / 
iff  s  y  s  t  cm!  t  emo )  ==  -  1  ) 

pe  r  ror !  "  RECEIVE  system  call  failed"); 
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3.  netV.c 

a.  Calling  Protocols 

This  module  contains  the  low-level  socket-managing  calls.  No  functions  in 
this  module  are  intended  for  application  programs.  This  module  is  only  linked  into  the 
send  and  receive  processes. 

b.  Code  and  Description 


*  * 
*  TITLE  I n t e r -Compu t e r  Comnun i c a t i on  Package  * 


*  NODULE  : 

* 

*  VERSION: 

*  DATE 

* 

*  AUTHOR  : 

* 


HISTORY: 


I n t e r -Compu t e r  Communication  Package 

netV.c 

5.0 

31  May  1988 
Theodore  H.  Barrow 


VERSION: 

1  0 

DATE 

19  November  1986 

AUTHOR  : 

Mi  chae l  J .  Zyda 

DESC. 

Contains  routines  conne 
two  machines  with  Unix 

VERSION: 

2.0 

DATE 

29  April  1987 

AUTHOR  : 

Michael  J .  Zyda 

DESC. 

Converted  to  work  with 

VERSION: 

3.0 

DATE 

27  May  1987 

AUTHOR  : 

Theodore  H.  Barrow 

DESC . 

Eliminated  excess  varia 

VERSION: 

4.0 

DATE 

2 I  Augus  t  1987 

AUTHOR  : 

Theodore  H.  Barrow 

DESC. 

Improved  reliability  of 

VERSION: 

5 . 0 

DATE 

31  May  1988 
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AUTHOR  :  Theodore  H.  Barrow 

DESC.  :  Added  start _broadcast()  and  broadcast_receive()  to  provide 
datagram  sockets  for  broadcast  use.  These  sockets  use  the 
default  Internet  broadcast  addressing. 


RECORD  OF  CHANGES 


‘Version*  Date  *  Author 
*  *  Change  Description 


*  Affected  *Re 

*  Modules  *Ve 

*  send . c  *4.0* 


*  4Jan88  *  T.  H.  Barrow  *  *  send. c  *4.0 

*  Changed  include  library  pathnames  for  IRIS  4D. *  receive. c  *4.0 
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/* 

This  segment  ,  when  linked  into  a  program  on  a  computer  with  a  UNIX  4  2  BSD 
operating  system,  will  allow  the  program  to  cormiun  i  ca  t  e  with  programs 
executing  on  other  computer  systems  over  an  Intel  net  network. 

*/ 

#de  fine  TRUE  1 

/*  include  files  for  UNIX  4.2  BSD.  These  are  all  called  from  the  bsd 

subdirectory  in  /usr/include  The  file  sys/types.h  also  exists  and  is 
included  when  bsd / sy s / t ype s . h  is  used.  This  was  done  for  ease  of  change 
if  and  when  Silicon  Graphics  changes  the  include  library  structure.  */ 
Ifincluue  <s  y  s  /  t  y  pe  s  .  h> 

#include  <sy s / socke t . h> 

#include  <b s d / ne t i ne t / i n . h> 

#include  <bsd/ne t db . h> 

The  connec t _s e r ve r ( remo t e_c 1 i en t _name ,  port_number)  function  performs 
the  actions  required  to  connect  a  server  system  to  a  remote  client  system 


int  c onnec t _se r ve r ( remo  t e_c 1 i en t _name  ,  port_number) 


char  r emo t e_c 1 i en t _n  ame [ ] ; 
int  por  t_numbe  r ; 

I 

char  *p t r_c 1 i en t_name ; 
int  1  oca  1 _se r ve r_socke t 
i  n  t  socke  t ( ) ; 
int  acc  ep  t (  )  ; 


/*  name  of  the  remote  client  system  */ 

/*  port  number  to  the  remote  client  system  */ 

/*  pointer  to  the  remote  client  system's  name  */ 

/*  local  socket  number  */ 

/*  function  that  opens  a  socket  */ 

/*  function  that  accepts  a  connection  from 
a  remote  client  socket  */ 


int  remote_c  l  ient_socket  =  -1;  /*  socket  number  of  remote  client  system  */ 

/  *  protocol  and  address  data  structure  for  socket  *  / 
static,  struct  sockaddr_in  address  =  {  AF_INET  ); 

long  remo t e_c 1 i en t _addr e s s :  /*  address  of  the  remote  client  system  */ 

short  r emo t e_c 1 i en t _po r t ;  /*  port  number  of  the  remote  client  system  */ 

int  add r e s s_ s i ze :  /*  size  of  address  of  remote  client  system  */ 


r.V, 


•Y> 

yi 

>  ■ -1 


/*  create  socket  structure  from  input  parameters  */ 

/*  get  a  pointer  to  the  remote  client  system’s  name  */ 
p  I  r_c  I  i  en  t  _  it  ante  =  r  emo  t  e_c  1  i  en  t  _n  ame  : 

/*  convert  the  remote  client  system  name  to  its  address. 

Note  that  ge t hos t by n ame ( )  requires  a  pointer  to  a  pointei  */ 
r  emo  tec  I  ient_ address  =  (long)gethostbyn  ame (&p  t  r _c 1 i en  t  _nnme  )  ; 

/ *  set  the  remote  client  port  number  above  the  system  reserved  ports 

by  adding  the  remote  client  port  number  to  the  number  of  reserved  ports 
remot  c_c  I  i  en  I  _por  t  =  IPPORT_RESERVH3  +  po r  t _nunibe  r ; 

/ *  r emo te  client  system  address  family  (Internet  in  this  case)  */ 
a  d  d  r  e  s  s . s i n  _  f  am i  I y  =  AF_ I NET 


3? 
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/*  place  the  remote  client  port  number  into  the  address  data  structure 
in  network  byte  order  */ 
add r e s s . s i n_po r t  =  h t on s ( r emo t e_c 1 i en t _po r t ) : 

/*  place  the  remote  client  system's  address  in  the  address  data  structure  */ 
add r e s s . s i n_add r . s_add r  =  r emo t e_c I i en t _add r e s s ; 

/*  find  number  of  bytes  in  the  remote  client  address  */ 
address_size  =  s i zeo f ( remo t e_c 1 i en t _add r e s s  )  ; 

/*  attempt  to  open  a  local  socket  * / 

I  oc a l_se r ve r_socke t  =  socke t (AF_INET , SOCK_STREAM,  0 ) ; 

i f ( 1 oc a  I _se r ve r_socke t  <  0) 

perror( "Server  couldn’t  open  a  local  socket:"): 
else 

I 

i  f ( b i nd ( 1 oc a l_se r ve r_socke t ,  ( c add r_ t )&addr e s s ,  s  i zeo f ( addr e s s  )  )  <  0) 
pe r ror ( "Se rve r  couldn’t  bind  address  to  local  socket:"); 

/*  set  the  maximum  number  of  remote  client  systems  to  be  connected  to  */ 

1 isten( local_server_ socket , SCM^XCONN) : 

p r i n t f ( "Se r ve r  waiting  to  connect  to  %s \n " , r emo t e_c 1 i en t _name ) ; 

/*  attempt  to  accept  a  connection  */ 

remot e_c 1 i en t_socke t  =  accept ( 1  oca  1 _se rve r_socke t ,  &address, 

&add  r  e  s s_s i ze  )  ; 

i f ! remot e_c  l  i  en t  socket  <  0) 

I 

/*  an  error  occurred  in  the  server  attempting  to 
accept  a  connection  from  remote  client  system  */ 
perror("Server  couldn’t  accept  connection  from  remote  client  system:”) 

shutdown! 1  oca l_se r ve r_socke t ,  2) ; 
close(local  server  socket); 

I 

/*  else  the  server  accepted  a  connection  from  the  remote  client  system  */ 

I 

/*  return  the  socket  number  of  the  remote  client  system  */ 
return! remot  e_cl ient_socket ) ; 


)  /*  connec t _s e r ve r  */ 


The  connec t _c l i en t ( remot e_se rve r_name ,  port_number)  function  performs 
all  the  actions  required  to  connect  a  client  system  to  a  remote  server 
system 


int  connec t _c I i en t ( remo t e_se rve r_name ,  port_number) 

char  remote_server_name[ ] ;  /*  name  of  the  remote  server  system  */ 

int  port_number;  /*  port  number  to  the  remote  server  system  */ 


int  local_cl ient_socket ;  /*  local  socket  number  */ 

int  socketf);  /*  function  that  opens  a  socket  */ 

/*  function  that  connects  local  socket  to  remote  server  socket  */ 
i n  t  connec  t (  )  ; 

int  remo t e_s e rve r_socke t ;  /*  socket  number  on  remote  server  system  */ 

/ *  the  protocol  and  address  data  structure  specified  for  the  socket  *  / 
static  struct  sockaddr_in  address  =  (  AF_INET  ); 

struct  hostent  * r emo t e_s e r ve r_add r e s s ;  /*  address  of  remote  server  system  */ 

short  r emot e_se rve r_por t ;  /*  port  number  of  remote  system  */ 


/*  create  socket  structure  from  input  parameters  */ 


/*  convert  the  remote  server  system  name  to  its  address. 

Note  that  ge t hos t byname  (  )  requires  a  pointer  only  in  this  case  */ 
remote_server_address  =  ge t ho s t byname ( remo t e_se rve r_name )  ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *)&address,  s i zeo f ( add  re s s  )  )  ; 

/*  copy  the  remote  server  address  structure  into  the  address  structure  */ 
b copy ( remot  e_server_address->h_addr  , 

(char  * )&addre s s . s i n_addr , 

remo te_server_address->h_length)  ; 

/*  set  remote  server  port  number  above  the  system  reserved  ports  by  adding 
the  user's  remote  server  port  number  to  the  number  of  reserved  ports  */ 
remo  t e_se rve r_po r t  =  I PPORT. RESERVED  +  port_number; 

/  *  remote  server  system  address  f am ity(  Internet  in  this  case)  *  / 
address . s in_fami ly  =  AF_ [NET ; 

/*  place  the  remote  server  port  number  into  the  address  structure 
in  network  byte  order  *  / 
add r e s s . s i n_po r t  =  h t on s ( r emo t e_ s e r v e r_po r t  )  ; 

/*  attempt  to  obtain  a  local  socket  */ 

1 oc a  1 _c 1 i en t _s ocke t  =  socket ( AE_ INbl ,  S OCX_ STREAM ,  0): 

i f (  1 oc a  1 _c 1 i en t _ socke t  <  0) 

pe r r o r ( "Cl i en t  couldn't  open  a  local  socket:"); 
else 
( 

/*  place  Internet  address  family  type  in  address  structure  */ 
add  res  s.sin_  family  =  AJF_  I  NET : 


/*  attempt  to  connect  local  client  socket  to  remote  server  socket  */ 
rentot e_se rve r^socke t  =  connect ( loca l_c 1 ient_socke  t ,  ( c add r_ t  )&add r e s s 

sizeof(address)); 

i  f ( r emo  t e_ s e r v e r _ s ocke t  <  0) 

I 

/*  error  occurred  in  attempting  to  connect  to  remote  server  socket 
pe r ro r ( "Cl i en t  couldn't  connect  to  the  remote  server  socket:"); 

shu t down( 1 oc a l_c 1 i en t _socke t ,  1)\ 
c 1 ose ( 1  oca l_c 1 i en  t _socke  t ) ; 

/*  set  1  oca l_c 1 i en t _socke t  so  that  negative  value  is 
always  returned  when  an  error  occurs 

*/ 

local  client  socket  =  remo t e_ s e r ve r  socket: 

I 

else 

/*  successfully  connected  to  the  remote  server  system  */ 

pr i n t f ( "Connec t i on  established  with  %s . \n" , remo t e_s e r ve r_name ) ; 

) 

/*  return  the  socket  number  of  the  local  client  system  */ 
return( local_cI ient_socket ) ; 

)  /*  connec t _c I i en t  */ 


The  s t a r t _b roadca s t (po r t _numbe r )  function  performs 

the  actions  required  to  initiate  a  datagram  broadcast  socket. 


int  s t a r t _b roadc a s t ( po r t _numbe r  ) 

int  po r t _numbe r ;  /*  port  number  for  the  remote  receiver  system  */ 

( 


i  n  t 

b roadc a s t _socke t ; 

/* 

local  socket  number  */ 

i  n  t 

socke  t () : 

/* 

function  that  opens  a  socket  */ 

i  n  t 

se  t  sockopt ( ) ; 

/* 

function  that  sets  a  socket  to 

allow 

broadc  a  s  t 

i  n  t 

on  =  TRUE; 

/* 

to  set  broadcast  toggle  on  for 

socke  t 

*/ 

/  *  protocol  and  address  data  structure  for  socket  *  / 
static  struct  sockaddr_in  address  =  {  AF_INET  ) : 

short  broadcas t_por t ;  /*  port  number  broadcast  heard  from  */ 


/*  create  local  socket  structure  from  input  parameters  */ 

/*  set  the  broadcast  port  number  above  the  system  reserved  ports 

by  adding  the  broadcast  port  number  to  the  number  of  reserved  ports  */ 
b roadc a s t _po r t  =  I PPORT_ RES ERVED  +■  port_number; 

/*  system  address  family  (Internet  in  this  case)  */ 
address . s in_f ami ly  =  AF_INET  ; 

/*  place  the  port  number  into  the  address  data  structure 
in  network  byte  order  */ 
address . s in_por t  =  h t ons ( b roadcas t _po r t  ) : 

/*  place  the  local  address  in  the  address  data  structure 
in  network  byte  order  */ 
addr e s s . s i n_addr . s_addr  =  h t on l ( INADDR_ANY)  ; 

/*  attempt  to  open  a  local  socket  */ 

broadcas t_socke t  =  socke  t (AF_INhl , SOCK_DGRAM,  0 ) ; 

i f ( broadcas t_socke t  <  0) 

perror( "Broadcaster  couldn't  open  a  local  socket:"); 
else 
I 

/*  set  the  b roadc a s t _socke t  for  broadcasting  */ 
i f ( se t sockopt (  b r oadc a s t _socke t  ,  SOL_SOCKET,  SO_BROADCAST . 

&on .  sizeof(on)  )  <  0) 

pe r r o r ( "Broadc a s t e r  couldn’t  set  socket  to  broadcast:"); 

else  if(bind(  b roadc a s t _socke t ,  (struct  sockaddr  *)&address, 
s i zeo f ( add r e s s  )  )  <  0) 

pe r ror ( "Broadcas t e r  couldn't  bind  to  local  socket:"); 
else 
( 

p r  i  n t f ( "Wa  i t i ng  to  b r oadc a s t \n" ) ; 

I 

1 

/*  return  the  socket  number  */ 
return(broadcast_socket  )  ; 


1  /  *  start  broadcast  *  / 


netV.c 


The  broadc as t _rece i ve ( broadc a s t e r_name , po r t _numbe r )  function  performs 
all  the  actions  required  to  set  up  a  broadcast  receiving  socket 


int  broadc ast_receive(broadcaste  r_name , por  t _numbe  r ) 

char  broadcas ter_name [ ] ;  /*  name  of  the  broadcaster  system  */ 


int  port_number; 


int  local_socket ; 
i n  t  socke  t ( ) ; 


/*  port  number  for  the  broadcaster  */ 


/*  local  socket  number  */ 

/*  function  that  opens  a  socket  */ 


int  broadcas t er_socke t ;  /*  socket  number  on  broadcaster  system  */ 

/*  the  protocol  and  address  data  s t rue t u re  spec i f i ed  for  the  socket  */ 
static  struct  sockaddr_in  address  =  (  AF_ INfcV  ); 

struct  hostent  *b roadc as t e r_add re s s ;  /*  address  of  broadcaster  system  */ 


short  broadcas t e r_por t ; 


/*  port  number  of  remote  system  */ 


/*  create  socket  structure  from  input  parameters  */ 

/*  convert  the  broadcaster  system  name  to  its  address. 

Note  that  ge thos t byname < )  requires  a  pointer  only  in  this  case  */ 

L  oadcas ter_address  =  ge t hos t byname ( broadca s t e r_name ) ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *)&address,  s i zeof ( addres s ) ) ; 

/*  copy  the  broadcaster  address  structure  into  the  address  structure  */ 
bcopy (broadcas  t  e r_addres s ->h_addr , 

(char  *  l&addr e s s . s i n_addr , 
broadcaster_address->h_length); 

/*  set  broadcaster  port  number  above  the  system  reserved  ports  by  adding 
the  user’s  broadcaster  port  number  to  the  number  of  reserved  ports  */ 
b r oadc a s t e r_po r t  =  IPPORT_RESERVED  +  port_number; 

/*  broadcaster  system  address  f ami  1 y (  In t e rne t  in  this  case)  */ 
add r e s s . s i n_f  ami  1 y  =  AF_ I NET ; 

/*  place  the  broadcaster  port  number  into  the  address  structure 
in  net  wo  rk  byte  order  */ 
add r e s s . s i n_po r t  =  h t ons ( b r oadc a s t e r_po r t  )  ; 

/*  attempt  to  obtain  a  local  socket  */ 
local_socket  =  socke  t ( AF_ INbl  .  SOCK_DGRAM,  0); 

i f (  1  oc a l _socke t  <  0) 

I 

pe r r o r ( "Rec e i ve r  couldn’t  open  a  local  socket:"): 


/*  attempt  to  connect  local  socket  to  broadcaster  socket  */ 
b roadc a s t e r_socke t  =  connect ( local_sockel ,  (struct  sockaddr  *)&address, 

sizeof(address)); 
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i f tbroadcas t e r_socke t  <  0) 

( 

/*  error  occurred  in  attempting  to  insert  broadcaster  information  */ 
pe r r o r ( "Rece i ve r  couldn't  find  broadcaster:"); 

s  liu  t  down  (  1  oc  a  1  _socke  t  ,  2); 
closet loca[_socket  )  ; 

/*  set  local_socket  so  that  negative  value  is 
always  returned  when  an  error  occurs 

*/ 

local_socket  =  broadcaster  socket; 

I 

else 

/*  successfully  listening  to  the  broadcaster  system  */ 
pr int f (" ready  to  receive  f rom  %s . \n" , b r oadca s t e r_name ) ; 

I 

/*  return  the  socket  number  of  the  local  system  */ 
return! local_socket ) ; 

|  /*  b r oadc a s t _r ece i ve  */ 
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receive.c 

#include  "shared. h" 

# i nc 1 ude  " g 1 . h " 

ma i n ( a  r  gc , a  r g v  ) 

i  11 1  argc:  /*  argument  count  */ 

char  *argv[];  /*  pointers  to  the  passed  in  arguments  */ 

( 

/  *  we  need  to  declare  character  variables  for  everything  passed  in  *  / 

char  shmi  ds t r ( 10] :  /*  shared  segment  string  holding  the  integer  key*/ 

int  shmid;  /*  integer  pulled  out  of  the  string  */ 

char  *segment;  /*  character  pointer  to  the  shared  segment  */ 

int  receivesem;  /*  receive  semaphore  */ 

char  ‘sharedsegment ( ) ; /*  create  shared  segment  function  */ 

char  mname[100];  /*  machine  name  */ 

char  portstr[10]:  /*  port  number  string  */ 

long  portnum:  /*  port  number  pulled  from  the  string  */ 

char  server [ 10] ;  /*  server  string  */ 

char  seqnostr[10]:  /  *  sequence  #  string  holding  integer  sequence  #  *  / 

long  sequencenum  =  0;  /*  integer  pulled  out  of  the  string  (default  0)  */ 

int  socket;  /*  the  opened  socket  descriptor  */ 

int  connec t _se rve r ( ) ; 

int  connec t_c 1 i en t () ; 

int  broadcas t _rece i ve ( ) ; 

int  receiver_is_free(); 

int  rece i ve r_shou ld_di e ( ) ; 

int  se.  an(  )  ;  /*  semaphore  creation  routine.  */ 

/*  pull  out  the  strings  from  the  argument  list  */ 
i  f  (  a rgc  <  5  ) 

I 

p r i n t f ( "RECEIVE :  incorrect  argument  count !\n"  ) : 
exit( 1 ) : 


/*  pull  out  the  shared  memory  string  */ 
st  rcpy ( shmi  dstr,argv[l]); 
s  sc  an  f  (  s  hnii  ds  t  r ,  "%d  "  ,&s  hmi  d  )  : 

/*  pull  out  the  machinename  string  */ 
st  rcpylmn amc . a  r  g  v [ 2  )  )  : 

/*  pull  out  the  port  number  string  */ 
strcpy(portsl r . a  r  g  v ( 3  ]  )  ; 
s  scan  f  (  por  t  s  t r, "%d" ,&po  r  t  num) ; 


receive.c 

/*  erf  ate  the  receive  semaphore  */ 
receivesem  =  semt ran(por tnum)  ; 

/*  pull  out  the  client/server  string  */ 
st  rcpy( server, argv[4]  )  ; 

/*  pull  out  the  sequence  number  string  */ 
i  f  (  arge  >  4  ) 

I 

strcpy(seqnostr,argv[5]); 
sscanf(seqnostr, "%d "  ,&s equenc enum)  ; 

) 

/*  attach  to  the  shared  memory  segment  */ 
i  f  (( in  t )(  segment  =  (char  *  )  shma  t  (  shmi  d ,  0,  0666))  <  0) 

( 

perror( "RECEIVE: shmat ”  ) ; 
exi t (0) ; 

) 

/*  create  the  shared  segment  address  to  use  */ 
segment  +=  sequencenum  *  MAXSHAREDS I ZE ; 

/*  open  the  socket  connection  to  the  named  machine  */ 
if ( st  rcmp( server , "server" )  ==  0) 

{ 

/*  we  should  open  as  the  server  */ 
socket  =  connec t_server  (mname .portnum) ; 

1 

else  i f ( s t rcmp( se rve r , " rece i ve " )  ==  0) 

( 

/*  we  should  open  as  the  broadcast  receiver*/ 
socket  =  broadcas t_rece i ve(mname ,por tnum)  ; 

else 

I 

/*  we  should  open  as  a  client  */ 
socket  »  connect  c 1 i en t  (mname , por t num) ; 

1 

/*  check  to  make  sure  socket  was  opened,  exit  if  not  */ 
i f ( socket  <  0) 

( 

pr i n t f ( "RECEIVE:  socket  connection  NOT  made!\n"); 
ex i t  (  1 )  ; 

I 


/*  the  infinite  loop...  */ 

i f ( st  rcrap( server , "receive" )  ==  0) 
whi 1 e (TRUE) 

( 

/*  should  the  receiver  die???  */ 
if(receiver_shoul d_di e( segmen  t , r ece i vesem) ) 

I 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  */ 
de  t  ach s ha  red segmen  t ( segmen  t ) ; 
s hu t down( socke t ,  0); 
close(socket); 
ex i t ( 0 )  ; 

I 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
i f( receiver_i s_f  ree( segmen  t  ) ) 


/*  check  socket  and  read  into  segment  if  proper  message  */ 
i f ( b r oadc a s t _ i n t o_s egmen t ( s oc ke t , s egmen t .mname , po r t num)  >  0) 
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/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  is  free,  i.e. 
the  data  has  been  read  out  */ 

P(  r ec e ivesem)  ; 


|  /*  end  while  true  for  broadcasting*/ 

else 

wh  i 1 e ( TRUE ) 

I 

/*  should  the  receiver  die???  */ 
if(receivcr  should  di e ( segmen t , r ece i ve s em) ) 

I 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  */ 
de  t  ach shared segmen  t ( segment ) ; 
shutdownf socke t ,  0); 
c 1 ose( socke  t ) ; 
exi t  to) ; 

) 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
if(receiver_is_free( segment ) ) 

( 

/*  read  socket  into  segment  */ 
read_socket_into  segment (socket , segmen t ) ; 

I 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  is  free,  i.e. 
the  data  has  been  read  out  */ 

P(  rece i ve sem)  ; 

)  /*  end  while  true  for  direct  connections*/ 
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5.  semaphore.c 


a.  Calling  Protocols 

This  module  repackages  the  low-level  semaphore  calls  into  a  P  and  a  V 
semaphore  operation.  No  functions  in  this  module  are  intended  for  application  programs. 

b.  Code  and  Description 


TITLE 

MXXJLE 

VERSION 

DATE 

AUTHOR 


In t e r -Compu t e r  Communication  Package 
s  end . c 
1.0 

11  February  1987 
Mi  chae 1  J .  Zyda 


HISTORY: 

VERSION:  1.0 


DATE 

AUTHOR 

DESC. 


11  February  1987 
Michael  J.  Zyda 


Implements  P  and  V  semaphore  operations  for  Unix  system  V.  * 
Based  on  an  example  f rom  Advanced  Unix  Progranmi ng .  * 

******»***»***************♦♦♦***********************♦*****************+****** 


RECORD  OF  CHANGES 

Version*  Date  *  Author 

Change  Description 


Affected 
Modu I e  s 


*Reqd* 
*Ve  r  s  * 

k  * 

* 
* 

'/ 
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#include  <sy s / t ype s . h> 
#include  <sys/ipc.h> 
#include  <sys/sem.h> 


semaphore.c 


int  semtran(key)  /*  translate  semaphore  key  to  ID  * 
i n  t  key: 

I 

int  s i d ; 

if  (.(.sid  =  semge t ( (key_t )key , 1 , 0666 1  IPC_CREAT)  ) 

I 

pe  r  ror ( " semge  t " ) ; 

) 

return(sid); 

) 


static  void  s emca I  1 ( s i d , op  )  /*  call  semop  */ 
int  sid; 
int  op; 

I 


st  rue  t  sembu  f  sb ; 

sb . sem_num  =  0; 
sb . s  em_op  =  op ; 
s  b  .  s  em_  fig  =  0 ; 

i f ( semop ( s i d ,&sb , 1 )  ==  -1) 

I 

pe  r  ro  r ( " semop " ) ; 

) 


I 


void  P(sid)  /*  acquire  semaphore  */ 
int  sid; 

I 

s  emc  allfsid,  -1); 

I 


void  V(sid)  /*  release  semaphore  */ 
int  sid; 

I 

s  emc  a  1 1 ( s  i  d  ,  1  )  ; 

I 
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6.  send.c 

a.  Calling  Protocols 

This  program  monitors  a  socket,  like  a  daemon.  It  is  spawned  transparently  to 
the  user  and  receives  its  initialization  data  through  the  command  line. 

b.  Code  and  Description 


TITLE 

MODULE 

VERSION 

DATE 

AUTHOR 


In  t  e  r -Compu  t  e  r  Cotnnun  i c a  t  i  on  Package 

send . c 

3.0 

31  May  1988 
Theodore  H.  Barrow 


HISTORY: 


VERSION: 

1.0 

DATE 

6  February  1987 

AUTHOR  : 

Michael  J.  Zyda 

DESC. 

Background  process 

VERSION: 

2.0 

DATE 

15  December  1987 

AUTHOR  : 

Theodore  H.  Barrow 

DESC. 

Added  capability  t 
and  use  it  to  get 

VERSION: 

3.0 

DATE 

31  May  1988 

AUTHOR  : 

Theodore  H.  Barrow 

DESC. 

Added  broadcast  ca 

* 

RECORD  OF  CHANGES  * 

* 

Version*  Date  *  Author  *  *  Affected  *Reqd* 

*  Change  Description  *  Modules  *Ve r s * 

♦  *  *  *  *  * 

*  *  *  * 


((include  " shared. h 
#  i  nc  1  ude  "  g  1  .  i' " 

ma i n( a  r gc , a  r g v  ) 


i n  t  argc;  /  *  argument  count  *  / 

char  *  a  r  g  v [  )  ;  / *  pointers  to  the  passed  in  arg  ume  n  t  s  * / 

/  *  we  need  to  declare  character  variables  for  everything  passed  in  * / 
char  shmi  ds t r [  10 ] ;  /*  shared  segment  string  holding  the  integer  shmid  */ 


int  shmid; 
char  *  s  e  gme  n  t  ; 


/*  integer  pulled  out  of  the  string  */ 

/  *  character  pointer  to  the  shared  se  gme  n  t  * / 


>t 

It 
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int  sends  em ; 


/*  send  semaphore  */ 


char  * sha redsegmen t ( ) ; /*  create  shared  segment  function  */ 

char  mname[100];  /*  machine  name  */ 

char  portstr[10];  /*  port  number  string  */ 

long  portnum:  /*  port  number  pulled  from  the  string  */ 


char  server[ 10];  /  *  server  string  *  / 

char  seqnos t r [ 10] ;  /*  sequence  #  string  holding  integer  sequence  #  */ 

long  sequencenum  =  0;  /*  integer  pulled  out  of  the  string  (default  0)  */ 


int  socket;  /*  the  opened  socket  descriptor  */ 

int  connec t _se t ve r ( ) ; 

int  connec t _c 1 i en t  ()  ; 

int  s t a r t _b roadc a s t (  )  ; 

int  sende r_h a s_da t a (  )  ; 

int  sende r_ shou 1 d_d  i  e ()  ; 

int  serat  ran(  )  ,  /*  semaphore  creation  routine.  */ 


/*  pull  out  the  strings  from  the  argument  list  */ 
i f ( a  rgc  <  5  ) 

1 

p r i n t f (  "SEbD:  incorrect  argument  count  !\n"  )  ; 
exit!  1  )  ; 


/*  pull  out  the  shared  memo ry  string  */ 
st  rcpyt shmid st  r  ,argv[  1  ]  )  ; 
s  s  c  an  f  (  s  linii  d  s  t  r  ,  "%d  ”  ,&s  hmi  d  )  ; 

/*  pull  out  the  machinename  string  */ 
s  t  rep;  mn  ame . a  r  g  v [ 2 | ) ; 

I*  pull  out  the  port  number  string  */ 
st icpy(port  st  r ,argv[3] >; 
sscanftport  st  r,  "9!;d"  ,&po  r  tnum)  ; 

/*  create  the  send  semaphore  */ 
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sendsem  =  semt  ran(portnum)  ; 

/*  pull  out  the  client/server  string  */ 
st  rcpy (server ,argv[4]  )  ; 

/*  pull  out  the  sequence  number  string  */ 
i  f  (  argc  >  4  ) 

I 

strcpy(seqnostr,argv[5]); 
sscanf(seqnostr, "%d" ,&s  equenc  enum)  ; 

I 

/*  attach  to  the  shared  memory  segment  */ 
i f (( int )( segment  =  (char  *  )  shmat ( shmid  ,  0,  0666))  <  0) 

I 

pe  r  ro  r ( "SEN5: shmat " ) ; 
e  x  i  t  ( 0 )  ; 

) 

/*  create  the  shared  segment  */ 
segment  +=  sequencenum  *  M4XSHAREDS I ZE ; 

/*  open  the  socket  connection  to  the  named  machine  */ 
i (( strcmp( server , "server"  )  ==  0) 

I 

/*  we  should  open  as  the  server  */ 
socket  =  connec t _se r ve r  (mn  ame , por t num) ; 

I 

else  if(  strcmp(  server,  "broadcast"  )  ==  0  ) 

I 

/*  we  should  open  as  a  broadcaster  */ 
socket  =  s t ar tbroadcas t (  portnum  ); 

I 

else 

I 

I*  we  should  open  as  a  client  */ 
socket  =  connec t_c 1 i en t  (mname , por t num) ; 


/*  check  to  make  sure  socket  was  opened,  exit  if  not  */ 
i f ( socke  t  <  0 ) 

I 

p r i n t f ( "SEM3:  socket  connection  NOT  madelNn"); 
exi t ( 1 ) ; 


/*  the  infinite  loop..  */ 

iff  s  t r  cmp (  server,  "broadcast"  )  ==  0  ) 
while! TRUE ) 


/  *  should  the  sender  die???  *  / 
if(sender_should_die(se  gmen  t  .sendsem)) 


/*  exit  after  detaching  se  gme  n  t 
detachsharedse  gme  n  t ( s  e  gme  n  t  ) : 
shut  down (soc  :;t  ,  1  ) ; 

close! socket ) ; 
ex i t ( 0 ) : 


and  cleaning  up  socket  *  / 


/*  if  there  is  data  in  inc  > 
i f( sender_has_data( s  egmen  t  ) ) 

i 


the  shared  memory  segment 


*/ 


/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 
send_socket_  f  r  om_  s  egmen  t( socket, port num, s  e  gmen  t  ) ; 


111 


V.V.V  ■ 


■  ’«s  ’ 

iVVy 


send.c 


/*  at  this  point,  sleep  until  we  receive  a  signal  from  the  graphics 
program.  The  signal  will  indicate  that  the  graphics  program 
has  put  more  data  into  the  shared  segment. 

*/ 

P ( sends  em )  : 

I  /*  end  while  true  for  broadcasting*/ 
else 

wh i 1 e ( TRUE ) 

I 

/*  should  the  sender  die???  */ 
if(sender_should  die( segment , s endsem) ) 

( 

/*  exit  after  detaching  segment  and  cleaning  up  socket  */ 
detachsharedsegment ( segment ) ; 
shu t down ( socke t .  1); 
c I ose ( socke  t ) ; 
ex i t (0) ; 

I 

/  *  if  there  is  data  in  the  shared  memo r y  s e gmen t ,  ...  *  / 

if(sender_has_data( s  egmen t ) ) 

/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 
wri te_socket_f  rom_s  egmen  t ( s  ocke  t , s  egmen t ) ; 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the  graphics 
program.  The  signal  will  indicate  that  the  graphics  program 
has  put  more  data  into  the  shared  segment. 

*/ 

P(serdsem); 

)  /*  end  while  true  for  direct  connection*/ 
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7.  shared.h 

a.  Calling  Protocols 

This  module  has  all  the  predefined  constants  and  type  definitions.  It  must  be 
included  in  the  application. 
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/* 

the  following  3  defines  are  the  changeable  parameters 
LARGESTREAD  MJST  be  divisible  by  4 

*/ 

#define  SEhOLOCATION  " /u s r /wo rk /ba r r ow/ sh a re3 / send"  /*  the  name  of  the  program 

to  run  for  the  sender  *  / 

#define  RECEIVELOCATION  “ /u s r /wo rk/ba r r ow/ s ha  re  3 / r ece i ve "  /*  the  name  of  program 

to  run  for  the  receiver  */ 

#define  LARGESTREAD  252  /*  the  largest  read  (i.e.  buffer  size)  */ 


/*  The  following  defines  are  constants  or  are  derived  from  LARGESTREAD  */ 

#define  SEN3EROFFSET  (LARGESTREAD  +  4)  /*  the  sender  data  starts  here  */ 

#define  WSEMJEROFFSET  ( SEI'DEROFFSET  /  4)  /*  long  word  offset  for  sender  data  */ 

#define  RECE I VEROFFSET  0  /*  the  receiver  data  starts  at  byte  0  */ 

#define  'WRECE I VEROFFSET  0  /*  the  receiver  data  starts  at  long  word  0  */ 

#define  PROTOCOLH3LDOFFSET  ( SEM3EROFFSET  *  2)  /*  holding  area  starts  after 

sender  area  *  / 

#de  fine  MAXSHAREDS IZE  ( PROTOCOLHOLDOFFSET  +  12)  /*  the  number  of  bytes  in  the 

shared  se gme n  t  * / 

#define  CHARACTER_TYPE  'B'  /*  code  for  characters  */ 

#define  INTEGERJTYPE  ’I’  /*  code  for  integers  */ 

#define  FLQAT_TYPE  'R'  /*  code  for  floats  */ 

#define  CHARACTER_ARRAY_TYPE  ’C’  /*  code  for  character  arrays  */ 

#define  INTEGER_ARRAY_TYPE  ’J’  /*  code  for  integer  arrays  */ 

#define  FLQAT_ARRAY_TYPE  ’S’  /*  code  for  float  arrays  */ 

#define  CHARACTER_S IZE  1  /*  character  size  in  bytes  */ 

#define  INTEGER_SIZE  sizeof(l)  /*  integer  size  in  bytes  */ 

#define  FLQAT_SIZE  sizeof(l.O)  /*  float  size  in  bytes  */ 

/*  the  following  is  the  structure  type  definition  needed  for  each  machine 

you  want  to  conmunicate  to. . . 

*/ 

typedef  struct  ( 

char  ‘segment;  /*  ptr  to  shared  memory  segment  */ 

int  shmid;  /*  system  generated  shared  mem.  id  */ 

int  sendsem;  /*  semaphore  used  to  wakeup  the  sender 

process  . 

*/ 

int  receivesem:  /*  semaphore  used  to  wakeup  the 
receiver  process... 


|  Mach  i  ne  ; 


/ 


8.  shareseg.c 


a.  Calling  Protocols 

This  module  contains  the  low-level  shared-memory  calls.  No  functions  in  this 
module  are  intended  for  application  programs. 

b.  Code  and  Description 


*  TITLE 

* 

*  NODULE 

* 

*  VERSION 

* 

*  DATE 

* 

*  AUTHOR 


In t e r -Compu t e r  Comnunicat ion  Package 
shareseg  .  c 


24  F  bruary  1988 
Theodore  H.  Barrow 


HISTORY: 

VERSION 


AUTHOR 


VERSION 


AUTHOR 


6  February  1987 
Michael  J .  Zyda 

Contains  routines  to  manage  shared  memory  segment.  Creation 
attachment,  detachment  and  deletion  are  all  covered. 


21  October  1987 
Theodore  H.  Barrow 

Added  function  dynami c sha r edsegnten t  to  allow  dynamic  memory 
allocation  after  comnunicat ions  link  established. 


VERSION 


AUTHOR 

DESC. 


15  December  1987 
Theodore  H.  Barrow 

Modified  function  dy n ami c sha r ed s egmen t  for  use  with  multiple 
links  First  call  does  shared  se  gme  nt  creation.  Subsequent 
calls  return  address  for  the  next  buffer  set. 


RECORD  OF  CHANGES 


♦Version*  Date  *  Author 
*  *  Change  Description 


<************< 


'  3.1  *  24Feb8 8 *  T.  H.  Barrow  * 

*  *  Added  compatibility  for  IRIS  4D. 

I****************************************** 


*  Affected  *Reqd* 

*  Modu 1 e  s  *Ve  rs* 

l*************  +  *****************4 


.**  +  ****  +  ***+  +  **  +  ***< 


shareseg.c 


#incltule  <sys/sysmacros  .h> 

#include  <stdio.h> 

#include  <sy s / t ype s . h> 

^include  <sys/ipc.h> 

#include  <sys/sitm.h> 

# i nc 1 ude  <g 1 . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation,  */ 

#de  fine  IRIS4D  1 
#de f i ne  IRIS3000  2 
#i fde  f  FLAT 

#de  f  i  ne  MACHINE  IRIS4D 
#e  1  s  e 

#de f i ne  MACHINE  IRIS3000 
#end i f 

char  *sharedsegmen  t(key,nbytes, shmi  d ) 
long  key;  /*  the  key  to  use  for  the  segment  ♦/ 

long  nbytes;  /*  the  number  of  bytes  in  the  segment  */ 
int  *shmid;  /*  returned  shared  memory  id  name  */ 

( 

char  *buf;  /*  temp  char  pointer  */ 

struct  shmi d_ds  junkbuf;  /*  I  don’t  care  what's  in  this  buffer  */ 

/*  allocate  a  shared  memory  segment  */ 

i f (  ( *  s  hmi d  =  s  hmg  e  t (  key,  nbytes,  0666  I  IPC_CREAT  ))  <  0  ) 

pe  r  ror  (  " shmge  t " )  ; 
exi t (0) ; 

) 

/*  attach  to  the  shared  memory  segment  */ 
i f ( ( in t ) (buf  =  (char  * ) shmat ( *shmi  d ,  0,  0666))  <  0) 

pe  r  ror ( " shmat " ) ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
if(  s  lime  t  1  (  shmid,  IPC_FMID,  &junkbuf  )  ==  -  1  ) 
pe  r  ror (  " shmc  t  1  "  )  ; 
ex i t ( 0 ) ; 

I 

f*  return  the  pointer  to  the  shared  segment  */ 
re  t  u  rn( bu  f  ) ; 

1 
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char  *a t t ach_wi t h i n_da t asegmen t (  key,  size,  shmid,  freespace  ) 
long  key:  /*  the  key  to  use  for  the  segment  */ 

long  size;  /*  the  number  of  bytes  in  the  segment  */ 

int  *shmid:  /*  returned  shared  memory  id  name  */ 

int  freespace:  /*  amount  freespace  desired  for  dynamic  allocation  */ 

I 

char  *enddata,  *buf;  /*  temporary  address  pointers  */ 

struct  shmid_ds  junkbuf;  /*  I  don't  care  what’s  in  this  buffer  */ 
char  *sbrk(),  *malloc(); 

/*  allocate  a  shared  memory  segment  */ 

if(  (*shmid  =  shmget(key,  size,  0666  I  IPC  CREAT)  )  <  0  ) 

( 

pe  r  ror ( " shmge t ”  )  : 
ex i t (0) ; 

) 

/*  Ensure  at  least  as  much  unallocated  space  as  freespace  indicates. 
Normally  the  top  of  the  data  region  is  incremented  more  than  the 
min  imum  required  to  mee  t  the  mal  loc()  request.  Using  ma 1 1 oc ( ) 
and  free()  ensures  that  this  mechanism  is  available  for  subsequent 
dynamic  memory  allocations.  Direct  use  of  sbrk(  )  system  call 
causes  the  mallocf)  mechanism  to  fail  on  subsequent  allocation 
requests.  freespace  is  cast  to  unsigned  to  meet  malloc()  spec.  */ 
free(  mallocf  ( un s i gned  )  f ree space  )); 

/*  find  the  top  of  data  region  */ 
enddata  =  sbrk(0) ; 

/*  round  up  to  the  next  page  boundary  for  attachment  of  shared 
memory  segment  */ 

buf  =  (char  *  )  ( (  i  n  t  )  endda  t  a  -  ( (  i  n  t  )  endda  t  a  %  SHvLBA )  +  SPMJBA)  ; 

/*  reset  top  of  data  region  to  be  above  shared  segment  */ 
if(  brk(  buf  +  size  )  <  0  ) 

I 

perror( "brk"  )  : 

/*  Since  there  was  an  error,  delete  the  segment  */ 
iff  shmctlf  shmid,  IPC_RMID,  &junkbuf  )  ==  -  1  ) 
pe  r  ror(  ”  shnic  t  I  "  )  ; 
ex i t ( -  1 )  ; 

I 

/*  attach  to  the  shared  memory  segment  at  the  calculated  address  */ 
iff  (  i  n  t  )  shma  t  (  *  shnii  d  .  buf,  0666)  <  0  ) 

I 

pe  r  ror ( " shma  t "  )  ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
iff  shmctlf  shmid,  IPC_BM1D,  &junkbuf  )  ==  -1  ) 
pe  r  ror  (  "  slime  t  l  ”  )  ; 
ex i t  (  0 )  ; 

I 

r e  t " rn (  buf  )  ; 

|  /*  a t t ach  wi t h i n_da t asegmen t (  )  */ 
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char  *dynami c shar edsegmen t ( nunmach i ne s ,  key,  nbytes,  shmid.  freespace) 
int  n unmn c h i ne s ;  /*  maximum  number  of  machines  to  be  initiated  */ 
long  key;  /*  the  key  to  use  for  the  segment  */ 

long  nbytes:  /*  the  number  of  bytes  in  the  segment  */ 

int  *shmid;  /*  returned  shared  memory  id  name  */ 

int  freespace;  /*  amount  freespace  desired  for  dynamic  allocation  */ 


static  Boolean  first  time  =  TRUE;  /*  allows  for  multiple  calls  */ 

static  char  * s t ar t sha r ed ;  /*  start  of  shared  memory  space  */ 

static  int  *holdshmid;  /*  holds  shmid  for  subsequent  calls  */ 

iff  f i r  s  t  t ime  ) 

( 

switch!  M\CHINE  ) 

( 

case  IRIS4D: 

start  shared  =  sha redsegmen t (  key,  nunmach i ne s *nby t e s ,  shmid  ); 
break; 

case  IRIS3000: 

startshared  =  (char  * ) a t t ach_wi t h in_da t a s egmen t  (  key, 

nunmach  ine s *nby t e s ,  shmid,  freespace  ) 

break; 
default : 

perrorf  "shareseg:  Unknown  machine”  ); 

)  /*  swi  t ch (  MACHINE  )  */ 

holdshmid  =  shmid; 
f  i  r  s  1 1 ime  =  FALSE; 

I 

else 

( 

/*  start  next  buffer  inmcdiately  above  last.  Return  the  same  shmid 
for  al!  buffers.  Assumes  all  buffers  are  same  size  (true  if  all 
from  same  shared. h  definition.  */ 
startshared  +=  nbytes; 

♦shmid  =  *ho!dshmid; 

I 

/*  return  pointer  to  the  proper  buffer  in  the  shared  segment  */ 
return!  startshared  ); 

I 


shareseg.c 


detachsha reds  egmen t ( segmen t  ) 

char  ‘segment:  /*  segment  to  detach  from  */ 


int  returnvalue; 

i  f  (  (  i  n  t  )  s  e  gme  n  t  %  SFMJ3A  !  =  0  ) 
returnf  1  )  ; 
else 

f 

iff  returnvalue  =  shmd t ( segmen t )  <  0  ) 
pe r  ror ( " shmd  t "  )  ; 
returnf  returnvalue  ); 

) 


de l e  t e  s ha  reds  egmen  t ( segmen  t , shmi  d ) 

char  ‘segment:  /*  character  pointer  to  the  shared  segment 

int  shmid;  /*  shared  memory  id. . .  */ 

( 

int  returnvalue; 

struct  shmid_ds  junkbuf;  /*  I  don’t  care  whnt's  in  this 

/*  detach  from  the  shared  segment  and  set  returnvalue  */ 
iff  returnvalue  =  de t achsharedsegmen t ( segmen t  )  ==  0  ) 

/*  remove  the  shared  segment  from  the  system  and  reset 
iff  returnvalue  =  shmc  1 1 ( shmi  d  ,  IPC_RMID,  &junkbuf)  < 
perrorf" shmc  t 1  ”  )  ; 


/ 


buffer  * / 


returnvalue  */ 
) 


returnf returnvalue)  ; 


9.  support.c 

a.  Calling  Protocols 

This  module  contains  functions  that  are  intended  for  the  application’s  use  and 
functions  that  are  used  exclusively  by  other  routines.  The  parameters  for  externally 
accessible  functions  are  described  below. 

i.  receiver Jias _data 

in t  rece i ver_has_da ta( instructure) 

Machine  * i ns t rue t ure ;  /*  includes 

char  *  ins t rue ture . segmen t  a  pointer  to  the  shared  segment  */ 

ii.  sender Js-free 

int  sender_is_free( ins tructure) 


Machine  *  ins t rue ture ;  /*  includes 

char  *instructure. segment 


a  pointer  to  the  shared  segment  */ 
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b.  Code  and  Description 


********************* 


*  TITLE 

* 

*  NODULE 

* 

*  VERSION 

* 

*  DATE 

*  AUTHOR 


I n  t  e  r -Compu  t  e  r  Comtiun  i  c  a  t  i  on  Package 
s  uppo r  t . c 

4.0 

31  May  1988 
Theodore  H.  Barrow 


* 

HISTORY: 

* 

* 

VERSION: 

1  0 

+ 

* 

* 

DATE 

6  February  1987 

* 

♦ 

* 

AUTHOR  : 

Mi  chael  J .  Zyda 

* 

* 

* 

* 

DESC. 

Contains  support  routines  for  shared  memory  conmunicat 
s  y  s  t  em . 

ions  * 

♦ 

* 

* 

VERSION: 

2.0 

* 

* 

DATE 

27  May  1987 

* 

* 

AUTHOR  : 

Theodore  H.  Barrow 

* 

* 

♦ 

DESC. 

Converted  functions  called  by  the  application 
a  structure  for  ease  of  use. 

program 

to  use  * 

* 

* 

VERSION. 

3.0 

♦ 

♦ 

DATE 

21  October  1987 

♦ 

* 

AUTHOR  : 

Theodore  H.  Barrow 

* 

* 

♦ 

♦ 

DESC. 

Removed  functions  for  reading  from  and  writing 
memory  segment  by  the  application  program. 

to  the 

shared  * 
* 

* 

♦ 

VERSION: 

4.0 

♦ 

* 

DATE 

31  May  1988 

* 

* 

AUTHOR  : 

Theodore  H.  Barrow 

* 

* 

* 

DESC. 

Added  functions  b roadc a s t _ i n t o_ s e gmen t  and 
send_s ocke  t  _ f  ront_s egmen  t  for  broadcasting  over 

+ 

datagram  socket* 

RECORD  OF  CHANGES 
*  Author 

Change  Description 


Affected  ‘Rei^U* 
Modu I e  s  *Ve  r  s  * 
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#irclu<le  "shared. h" 

# i nc 1 ude  <g 1 . h> 

(♦include  <bsd/ s y s / t ype s . h> 

(♦include  <s y s / s ocke t . h> 

#include  <b sd/ne t i ne t / i n . h> 

(♦include  <b  s  d  /  ne  t  db  .  h> 

/*  the  following  routine  sets  up  buffer  area  */ 
init_shared_buffer( segmen  t  ) 

char  ’segment ;  /*  pointer  to  the  shared  segment  */ 

I 

free_sender(  segment  ); 
f r ee_r ec e i ve r (  segment  )  ; 

•(segment  +  PRCfTOCOLHOLDO  FFSET  +  9)  =  ’\0’; 

I 

/*  the  following  routine  writes  zeroes  at  the  top  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
va 1  id. 

*/ 

free_sender( segmen  t  ) 

char  ’segment ;  /*  pointer  to  the  shared  segment  */ 

( 

/*  the  following  line  zeroes  the  first  four  bytes  of  the  sender  part 
of  the  shared  memory  segment,  ’segment’  is  a  character  pointer. 

I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 

*/ 

•((tong  ‘(segment  +  WSEN5EROFFSET)  =  0; 

) 


/*  this  following  routine  writes  zeroes  at  the  top  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
va 1  id. 

*/ 

free_receiver( segment  ) 

char  ’segment ;  /•  pointer  to  the  shared  segment  •/ 

I 

/*  the  following  line  zeross  the  first  four  bytes  of  the  receiver  part 
of  the  shared  memory  segn.ei't.  ’segment’  is  a  character  pointer. 

I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 

•((long  ‘(segment  +  \M*ECEIVL  .OFFSET)  =  0: 


l?j,ri'7<rjv*mnviY\irtL  riTOK.wnfww, 


supports 

/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 
segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 

*/ 

int  receiver_has_data( instructure) 

Machine  * i ns t r uc t u r e ;  /*  includes 

char  *ins  t  ructure . segment  a  pointer  to  the  shared  segment  */ 


if(*((long  *  )  i  n s t rue t u r e ->segmen t  +  WRECEIVEROFFSET)  >  0) 

I 

return! TRUE ) ; 

I 

else 

I 

r  e  t  u  r  n ( FALSE )  : 

I 

I 


I*  the  following  routine  tests  the  first  4  bytes  of  the  sender 
segment  to  see  if  they  are  non-zero. 

*/ 

int  s  ende  r_h  a  s_da  t  a  (  s  egnien  t  ) 

char  ’segment;  /*  pointer  to  the  shared  segment  */ 


i f ( *  (  ( long  ‘(segment  +  W3EN3EROFFSET  )  >  0) 

I 

r  e  t  u  r  n ( TRUE ) ; 

I 

else 

I 

return! FALSE ) : 

I 

I 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 
segment  to  see  if  they  are  less  than  zero. 

*/ 

int  r  ec  e  i  ve  r_shou  1  tl_d  i  e  (  s  egmen  t  ) 


char  ’segment:  /*  pointer  to  the  shared  segment  */ 


if(*((long  *)  segment  +  ^^RECEIVEROFFSET)  <  0) 

( 

return! TRUE ) ; 

I 

else 

I 

return! FALSE )  : 

) 

I 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 
s e gme nt  to  see  if  they  are  less  than  zero. 

*/ 

int  s ende r_shou 1 d_d i e ! s egmen t  ) 


char  ’segment;  /*  pointer  to  the  shared  segment  */ 


I 


if(*!f long  *) segment  +  WSEN3EROFFSET)  <  0) 

I 

return! TRUE ) ; 

I 

else 

I 

return! FALSE)  ; 


1 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 
segment  to  see  if  they  are  non-zero. 

*/ 

int  receive  r_i s_free( segment  ) 

char  *  segment:  /*  pointer  to  the  shared  segment  */ 

I 

if(*((long  *)  segment  +  >\RECEIVEROFFSET)  ==  0) 

( 

return! TRUE ) ; 

I 

else 

( 

return! FALSE ) ; 

I 

) 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 
segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 

*/ 

int  sender_is_free( instructure) 

Machine  *in structure:  /*  includes 

char  * i ns t rue t ure . segmen t  a  pointer  to  the  shared  segment  */ 

( 

if!*!(long  *  )  i ns t rue t u re ->segmen t  +  WSEM5EROFFSET)  ==  0) 

( 

re  turnfTRUE) ; 

1 

else 

( 

return!  FALSE ) ; 


) 


I 
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/*  the  following  routine  reads  on  the  input  socket  into  the  receiver  segment.*/ 

read_socket_int  o_s  egmen t (socket , segmen  t ) 

int  socket:  /*  a  socket  descriptor  */ 

char  *  s  e  gme  nt:  /  *  a  ptr  to  the  shared  se  gme  n  t  * / 

I 

long  nbytes;  /*  the  number  of  bytes  read  in  */ 
char  t  emp l LARGESTREAD] ; 


/*  read  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segmen t  . 

*/ 

nbytes  =  read( socke t , t emp , LARGESTREAD) ; 
i f ( nby  t  e  s  <=  0 ) 

I 

/*  the  following  routine  calls  are  conmented  out  for  the  following 
reason: 

nbytes  <=  0  means  that  the  socket  has  been  broken. 

This  routine  is  called  by  the  receiver  process  so  the  only 
intelligent  thing  to  do  is  to  terminate  the  receiver  process, 
i . e .  call  exit... 

pe  r  ror ( " read" ) ; 

p  r  i  n  t  f  (  "  READ_SOQtET_  INTO_SE<3VEOT :  number  of  bytes  read  =  %d\n " , nby t e s ) ; 

*/ 

shu  t  down (  socket,  2  ); 
close(  socket  ); 
exi t ( 1 ) ; 

I 

/*  copy  the  data  into  the  shared  segment  */ 
memcpy( ( segment  +  RECEIVEROFFSET  +  4 ) , t  emp , nby t e s ) ; 

/*  set  the  number  of  bytes  in  the  shared  segment  */ 

•((long  *)  segment  +  \MtECEIVEROFFSET)  =  nbytes; 


*  VW/vVvVT 
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/*  the  following  routine  writes  the  data  from  the  sender  side 
of  the  shared  se gme nt  to  the  socket  *  / 


write_socket_fr  om_s  egmen  t (socket  , segmen t  ) 
int  socket;  /*  socket  descriptor  ’/ 

char  ’segment;  /’  pointer  to  the  shared  segment  */ 

1 


to 

'<1 

# 

to 


long  nbytes;  /*  the  number  of  bytes  to  write  */ 
char  t emp [LARGESTREAD]  ; 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segmen  t  . 

*/ 


memcpy( temp,  ( (char  ’) segment  +  SEM3EROFFSET  +  4), 

♦((long  ‘(segment  +  WSEI'DEROFFSET) ) ; 


/*  write  the  data  to  the  socket  */ 

nbytes  =  wr  i  t  e  (  socke  t  ,  t  emp ,  ‘((long  ’(segment  +  ’'W5EM5EROFFSET)  )  ; 


if(nbytes  <=  0  II  nbytes  !=  *((long  ’(segment  +  W5ENDEROFFSET) ) 
/* 

This  error  indicates  the  socket  is  broken.  Just  exit  the 
sende  r  process. 


pe  r  ror ( "wr i t  e" ) ; 

p  r  i  n  t  f  ( ,rWRITE_SOCKET_FRCM_SECNENT :  number  of  bytes  written  =  %d\n 11  ,  nby  t  e  s  )  ; 

pr  i  n  t  f  (  "Numbe  r  of  bytes  in  shared  segment  =  %d\n" , * ( ( 1 ong  ’(segment  +  WSENDEROFFSF.T ) ( ; 


shut  down  (  socket 
close(  socket  ); 
exi t ( 1 ) ; 


2  ): 


/*  free  the  sender  segment  */ 
free_sender( segmen t  )  ; 


u 


// 


3? 


ft 

§3 
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/*  The  following  routine  receives  on  the  input  datagram  socket. 

If  the  message  matches  the  mname  and  portnum  it  is  copied  into  the 
receiver  area  of  the  shared  memory  segment. 

0  is  returned  if  the  message  does  not  match  mname  and  portnum. 
the  number  of  bytes  read  is  returned  if  it  does  match.  */ 

int  broadcast_int  o_segmen  t(socket,se  gmen  t  .mname .port  num) 

int  socket;  /*  a  socket  descriptor  * / 

char  “segment;  /*  a  ptr  to  the  shared  segment  */ 

char  mname[];  /  *  machine  name  of  broadcaster  */ 

long  portnum;  /*  port  number  of  broadcaster  */ 


long  nbytes;  /*  the  number  of  bytes  read  in  */ 

char  t  emp [ LARGESTREAD] ; 

int  flags  =  0;  /*  flags  =  0  indicates  none  set  */ 

struct  sockaddr_in  who;  /*  Internet  structure  for  message  sender  address  */ 

int  wholen:  /*  length  of  received  address  struct  who  */ 

struct  hostent  ‘broadcaster;  /*  pointer  to  structure  with  info  on 

broadcaster  */ 

static  long  b roadc a s t _addr e s s ;  /*  address  of  broadcaster  * / 
static  short  broadcas t_por t ;  /*  port  of  broadcaster  */ 

static  Boolean  first  time  =  TRUE: 


/  *  read  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment.  This  also  allows  checking  for  match  with  desired  broadcaster. 

*/ 

nbytes  =  recvf rom(  socket,  temp,  LARGESTREAD,  flags, 

(struct  sockaddr  *)&who,  &wholen  ); 

i f ( nby  t e  s  <=  0) 

I 

perror( "recvf  rom: " )  ; 

) 

else 

I 

i f (  f i r  s  t  t  ime  ) 

I 

/*  determine  desired  broadcaster  address  and  port  */ 
b  roadc  as  t  _po  r  t  =  litonst  (short  Iportnum)  ; 

broadcaster  =  (struct  hostent  *  )  ge t ho s t by name (  mname  ); 

bcopy(  b r oadc a s t e r - >h_add r ,  (char  *  )&b r oadc a s t _add r e s s  , 
b  roadc  a  s  t  e  r ->li_  1  eng  t  h  ); 


if(  (broad c a st_ address  ==  who . s i n_add r . s_add r )  <&& 
( b r oadc a s t _po r t  ==  who . s i n_por t )  ) 
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/*  copy  (he  data  into  the  shared  segment  */ 
memcpy  (  (  segmen  t  +  RECEIVEROFFSET  +  4  )  ,  t  etnp  ,  nby  t  e  s  )  : 


/*  set  the  number  of  bytes  in  the  shared  segment  */ 
long  *) segment  +  NVRECEIVEROFFSET )  =  nbytes; 


nbytes  =  0; 

/*  Set  nbytes  to  0  so  return  of  function  indicates  no  match  */ 


return(  nbytes  ): 
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/*  the  following  routine  sends  the  data  from  the  sender  side 
of  the  shared  segment  to  the  socket  for  broadcast  */ 


send_socket_f  rom_ segmen  t ( socket, por  t  num, segmen t  ) 


i  n  t  socke  t 


long  portnum; 
char  *segmen  t 


I ong  nby  t  es  : 


/*  socket  descriptor  */ 

/*  port  number  of  broadcaster  */ 

/*  pointer  to  the  shared  segment  */ 


/*  the  number  of  bytes  to  write  */ 


char  t  emp [LARGES TREAD] ; 
short  broadcas t e r_por t : 
static  Boolean  first  time  =  TRUE; 

static  struct  sockaddr_in  network  =  (  AF_INfcl  );  /*  structure  for  broadcast 

add  re  s s  *  / 

i  f  (  f  i  r  s  1 1  ime  ) 

( 

broadcas t e r_po r t  =  I PPORTJRESERVED  +  portnum; 

/*  Set  up  broadcasting  address  structure  */ 
ne twork . s i n_f  ami ly  =  AF_INET; 

ne twork . s i n_addr . s_addr  =  h tonl ( INADDR_BROADCAST) ; 
ne  twork . s  i  n_po r t  =  h t ons  ( broadca s t e r_por t ) ; 

first  time  =  FALSE; 

I 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment  . 

*/ 

memcpy( temp, ( (char  *) segment  +  SENJEROFFSET  +4), 

•((long  *)segment  +  WSEbDEROFFSET) )  ; 

/•  broadcast  the  data  through  the  socket  */ 

nbytes  =  sendto(  socket,  temp,  *((long  *)segment  +  W5EM>EROFFSET) ,  0, 

(struct  sockaddr  *)&network,  s i zeof ( ne twork )  ); 

if(nbytes  <=  0  II  nbytes  !=  *((long  *)segment  +  WSEIOEROFFSET) ) 

I 

/* 

This  error  indicates  the  socket  is  broken.  Just  exit  the 
s ende r  process. 

•/ 

pe  r  r o  r  (  "wr i t  e "  )  ; 

p  r  i  n  t  f  (  "V»R  ITE_SOCKET_FRCM_SEC2vE'rr :  number  of  bytes  written  =  %d\n  "  ,  nby  t  e  s  )  ; 
p r i n t f ( "Numbe r  of  bytes  in  shared  segment  =  %d\n" , * ( ( 1 ong  *)segment  +  WSENDEROFFSET) ) ; 
shutdown(  socket,  2  ); 
close(  socket  ) ; 
e  x  i  t  (  1  )  ; 

I 

/*  free  the  sender  segment  */ 
free_sender( segmen  t  )  ; 


m 
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/*  the  following  routine  deletes  the  sender  by  writing 
a  negative  byte  count  into  the  shared  segment 
and  then  waking  up  the  sender. 

*/ 


ki  I  l_sende  r ( segmen  t . sendsem) 


char  *  s  e  gme  nt;  /  *  ptr  to  the  se  gme n  t  ‘  / 


int  sendsem; 


/*  semaphore  to  the  sender  */ 


/*  write  a  negative  number  into  the  byte  count  field.  */ 
‘((long  *)  segment  +  V^SEbDEROFFSET )  =  -1; 


/*  at  this  point,  we  should  send  a  wakeup  to  the  sender  program, 
the  sender  will  read  the  bad  byte  count  and  exit. 


V(  sendsem)  ; 


/*  the  following  routine  deletes  the  receiver  by  writing 
a  negative  byte  count  into  the  shared  segment 
and  then  waking  up  the  receiver. 

*/ 


kill_receiver(  segmen  t , rece i ve  sem) 


char  ‘segment;  /*  ptr  to  the  segment  */ 


int  receivesem; 


/*  semaphore  to  the  receiver  */ 


/*  we  do  not  wait  until  the  receiver  segment  is  free  here 
as  the  process  that  calls  this  routine  should  already 
have  read  the  last  piece  of  data. 

*/ 


/*  write  a  negative  number  into  the  byte  count  field.  */ 
‘((long  *)segnient  +  WECEIVEROFFSET)  =  -1; 


/*  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 
the  receiver  will  read  the  bad  byte  count  and  exit. 


V( rece  i  ve  sem)  ; 


I 


I 
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APPENDIX  B  -  Tl  Explorer  Module  descriptions 


All  functions,  methods,  and  flavor  are  contained  in  file  irisflavor.lisp. 


1 .  Calling  Protocols 

The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 
application’s  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 
parameters  for  externally  accessible  functions  and  methods  are  described  below. 

a.  iris 

(defun  iris  (x)  ;where  x  is  number  of  iris  machine  desired 

b.  start-iris 

(defmethod  (conversat ion-wi th- i ri s  :start-iris) 

() 

c.  get-iris 

(defmethod  (conversat ion-wi th- i ri s  :get-iris) 

() 

d.  put- iris 

(defmethod  ( conve r s a t i on-wi  t h- i r i s  :put-iris) 

( object  ) 

(let*  ((buffer  ( cond 

((equal  (type-of  object)  'bignum)  ( conve r t - numbe r - t o- s t r i ng  object)) 

((equal  (type-of  object)  ’fixnum)  (convert -number- to- s t  ring  object)) 
((equal  (type-of  object)  ’float)  ( conve r t - numbe r - t o- s t r i ng  object)) 
((equal  (type-of  object)  ’string)  object) 

(t  "error”)  )) 

e.  stop- iris 

(defmethod  ( convers at i on-wi th- i r i s  :stop-iris) 

() 

f.  reuse-iris 

(defmethod  ( conve rsa t i on-wi t h- i r i s  :reuse-iris) 

(  ) 
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2.  Code  and  Description 

(defmncro  loopfor  (var  init  test  expl  &optional  exp2  exp3  exp4  exp5 ) 

‘  (  pi  Oji  (  i 

(setq  .var  ,init) 
t  ag 
,  exp  1 
,  exp2 
.  exp3 
,  exp4 
,  exp5 

(setq  ,var  (1+  ,var)) 

(if  (=  ,var  .test)  (return  t)  (go  tag))  )  ) 

(defun  con ve r t - numbe r - t o- s t r ing  (n) 

( pr i nc - t o - s t r i ng  n)  ) 

(defun  conve r t - s t r ing- t o- in t ege r  (str  &optionai  (radix  10)) 

(do  ((j  0  (+  j  1)) 

(n  0  (+  (*  n  radix)  ( d i g i t - cha r - p  (char  str  j)  radix)))  ) 

( (=  j  (1 ength  str))  n)  )  ) 

(defun  f i nd - pe r i od- i ndex  (str) 

(catch  'exit 

(dotimes  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  0)) 

(throw  'exit  x)  )  )  )  ) 

(defun  ge t - le f t s i de -of - rea  1  (str  &optional  (radix  10)) 

(do  ((j  0  (1+  j  )) 

(n  0  (+  (*  n  radix)  ( di g i t - cha r -p  (char  str  j)  radix)))  ) 

((or  (null  (digi t -char-p  (char  str  j)  radix))  (=  j  (length  st  r)))  n)  )  ) 

(defun  ge t - r igh t s i de -of  -  real  (str  ^optional  (radix  10)) 

(do  ((index  (1+  ( f i nd - pe r i od- i ndex  str))  (1+  index)) 

(factor  0.10  (*  factor  0.10)) 

(n  0.0  (+  n  (*  factor  ( d i g i t - cha r -p  (char  str  index)  radix))))  ) 

((=  index  (length  str))  n)  )  ) 

(defun  conve r t - s t r i ng- t o- rea 1  (str  &optional  (radix  10)) 

(+  (float  ( ge t -  1 e f t s i de - of - rea 1  str  radix))  ( ge t - r i gh t s i de - o f - r ea 1  str  radix))  ) 


( de  f  v  a  r 
(defvar 

* t cp -hand  1 e r  l  *  (send  i  p ::* t cp-hand 1 e r* 

* t cp - hand  1 e r2*  (send  i p  :  : * t cp - hand  1 e r * 

'•  ge«  -port  )  ) 

: ge  t -port ) ) 

( de  f  va  r 
(defvar 

* i r i s 1  - po r t 1  *  1027) 

*irisl-port2*  1026 ) 

;  this  is  the 
;  this  is  the 

send  port 
receive  port 

(defvar 

(defvar 

(defvar 

*  i  r i s  1  -  add  re  s  s  *  3221866502) 

*  i  r  i  s 2 -  add r e s s *  3221866504) 

* i r i s 3 -  add r e s s *  3221866505) 

(defvar 

*dest  address*  nil) 

;  the  tcp-ip  or  internet  address 
:  look  in  network  configuration 

( de  f  un  i 

iris  ( x ) 

(cond  ((equal  x  1)  (setq  *  d  e  s  t -address*  *irisl-ad dress*)) 
((equal  x  3)  (setq  *dest-address*  *iris3  -  address*)) 

(t  (setq  *de s t - add r e s s *  * i r i s 2  -  add r e s s *  )  )  )  ) 


(defflavor  con  ve  r  s  a  t  ion -wi  t  h  -  i  r  i  s  (  (  t  a  I  k  i  n  g  -  po  r  t  -  nunibe  r  *  i  r  i  s  1  -  po  r  t  1  *  ) 

(listening-port- numbe  r  *irisl-port2*) 

( t a  1 k i ng - po r t  * t cp- hand  1 e r 1  *  ) 

(listening-port  *tcp-handler2*) 

(destination  *des  t -address*  )  ) 
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( ) 

:gel table-instance-variables 
set  table- instance-variables 
i n i t ab 1 e - i n s t anc e - v a r i ab I e s  ) 


(defmethod  ( con ve r s a t i on - wi t h - i r i s  :start-iris) 

(  ) 

(progn 

(send  talking-port  :open 
:  ac  t i ve 


ta (king-port -number 
destination 


tcp  will  begin  the  procedure  to  establish 
connection  (default  vs  tpassive) 
port  number  of  destination  host 
machine  name  or  address  if  blank  and 
in  ’passive  mode  local  machine  waits  for 
c onnec  t i on 

set  max  seconds  before  read  request  times  out 


30  ) 

(send  1  i  s t en i ng- po r t  :open 

: ac  t i ve  ;  : pa  s  s i ve 

1  istening-port -number 
destination 
30  ) 

’"A  conversation  with  the  iris  machine  has  been  established"  )  ) 

(defmethod  (conve rsat ion-wi th- iris  :reuse-iris) 

() 

(setq  * t cp - hand  1  e r  1  *  (send  i p :  : * t cp- hand  1 e r *  :get-port) 

* t cp - hand  1 e r 2*  (send  i p :  : * t cp  -  hand l e r *  :get-port) 
talking-port  * t cp -h andl e r 1  * 
listening-port  * t cp- hand  1 c r2*  )  ) 

(defmethod  ( con ve r s a t i on -wi  t h - i r i s  :get-iris) 

l  ) 

(let*  ((typebuffer  "  ") 

(  1  eng t  hbuf  f e  r  "  " ) 

(buffer  "  " ) 

(buffer- 1  eng  t  hi)) 

(progn 

(send  listening-port  :receive 
typebuffer 
buf  fer- length 
30 

:  wa  i  t  ) 

(send  1 i s t en i ng -por t  :receive 
lengthbuf fer 
4 

30 

:  wa  i  t  ) 

(setq  buf f e r -  1  eng t h  ( con ve r t - s t r i ng - t o -  i n t ege r 
(setq  buffer  (make-string  bu f f e r -  1  eng t h  :initit 
(send  1 i s t en i ng -po r t  (receive 
buffer 

bu  f  f  e  r -  I  eng  t  h 

30 


I  eng  I hbu  f  f  e  r  )  ) 

1  - e I  erne  nl  (character  32))) 


(  c  ond 


:wait  ) 
( (equal 
( (equal 
((equal 
( t  nil) 


t  ypebu  f  f  e  r 
t  ypebu  f  f  e  r 
t  ypebu  f  f  e  r 
)  )  )  ) 


"l")  (convert -string-to-integer  buffer)) 
"R" )  (convert  - s  t  ring- to- rea 1  buffer)) 
"C" )  buffer) 


( de  fme  t  hod 
(let 


(conversation-with-iris  : pu  t - i r i s  ) 

(object ) 

((buffer  ( cond 

((equal  (type-of  object)  ’bignum)  (convert -number  -  to- string  object)) 

((equal  (type-of  object)  fixnum)  (convert-number- to-st  ring  object)) 
((equal  (type-of  object)  ’float)  (convert -number- to-s  t  ring  object)) 
((equal  (type-of  object)  ’string)  object) 

( t  "error"  )  )  ) 

(  bu f f e r - I  eng t h  (length  buffer)) 


135 


Explorer  irisflavor.lisp 

(typebuffer  (cond  ((equal  (type-of  object)  ’bignum)  "I") 

((equal  (type-of  object)  ’fixnum)  "I") 

((equal  (type-of  object)  'float)  "R" ) 

((equal  (type-of  object)  'string)  "C” ) 

( t  "C" )  ) ) 

(  1  eng  t  hbu  f  f  e  r  ( conve r t - numbe r - t o - s t r i ng  bu  f  f  e  r  -  I  eng  t  h  )  ) 

( *  I oopva r i ab 1 e*  0)  ) 

(progn 

(send  talking-port  : send 
t  ypebu  f  f  e  r 
1 

n  i  1 
nil  ) 

(if  (=  (length  1  eng t hbu f f e r  )  4) 

(send  talking-port  :  send 
1  engt  hbuf  fe  r 
4 

n  i  i 
nil  ) 

(progn 

(loopfor  *  I oopvar i ab 1 e *  (length  1  eng t hbu f f e r )  4 

(send  talking-port  :  send  "0"  1  nil  r.  i  1  )  ) 

(send  talking-port  : send  lengthbuffer  (length  1  eng t hbu f f e r  )  nil  nil)  )  ) 

(send  talking-port  :send 
buffer 

buffer-length 

t 

nil)))) 

(defmethod  ( con ve r s a t i on  -  wi  t h - i  r  i  s  :stop-iris) 

(  ) 

(progn  (send  talking-port  rclose)  (send  I i s t en i ng  po r t  :close))  ) 
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APPENDIX  C  -  Symbolics  Module  Descriptions 


All  functions,  methods,  and  flavor  are  contained  in  file  irisflavor.lisp. 


1 .  Calling  Protocols 

The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 
application’s  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 
parameters  for  externally  accessible  functions  and  methods  are  described  below, 
a.  select-host 

(defun  select-host  (host-name) 


start-iris 


(defmethod  (:start-iris  conve r s a t i on-wi t h- i r i s ) 

() 


c.  net- iris 


(defmethod  (:get-iris  conve r sat i on-wi th- i r i s ) 


() 


d.  put-iris 


(defmethod  (:put-iris  conve r s a t ion -wi t h- i r i s ) 

( ob j ec  t ) 

(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  ( conve r t - nunibe r - t o- s t r i ng  object)) 

((equal  (type-of  object)  ’fixnum)  (conver t -number ■ to-s t ring  object)) 
((equal  (type-of  object)  ' s i ngle - f I oa t  )  ( conve r t - nunibe r - t o - s t r i ng  object)) 
((equal  (type-of  object)  ’string)  object) 

(t  "error")  )) 


e.  stop- iris 


(defmethod  (:stop-iris  conve rsa t i on-wi th- i r i s ) 


() 


f.  reuse-iris 


(defmethod  (:reuse-iris  conve r s at i on-wi t h- i r i s ) 


() 
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2.  Code  and  Description 

-  *  -  Mode  :  LISP;  Syntax:  Conmon  -  1  i  s  p  ;  Package:  USER  -*- 

;  handy  macro  to  have  in  the  send  message  farthur  down 

(defmacro  loopfor  (var  init  test  expl  &optional  exp2  exp3  exp4  exp5) 
' (prog  ( ) 

(setq  ,var  ,init) 
t  ag 

expl 
.  exp2 
,  exp3 
.  exp4 
,  exp5 

(setq  ,var  (1+  ,var)) 

(if  (=  ,var  .test)  (return  t)  (go  tag))  )  ) 


(defun  convert -number- to-string  (n) 

(princ-to-string  n)  ) 

(defun  con ve r t - s t r ing - t o- in t ege r  (str  &optional  (radix  10)) 

(do  ( ( j  0  (+  j  1 ) ) 

(n  0  (+  (*  n  radix)  ( d i g i t - c h a r - p  (char  str  j)  radix)))  ) 
(  (=  j  (1  eng t  h  str))  n  )  )  ) 

(defun  f  i  nd - pe r i od - i ndex  (str) 

(catch  'exit 

(dotimes  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  0)) 

(throw  ’exit  x)  )  )  )  ) 


(defun  ge t -  1 e f t s i de - of - rea  1  (str  &optional  (radix  10)) 

(do  ( ( j  0  (1+  j ) ) 

(n  0  (+  (*  n  radix)  ( d i g i t - cha r -p  (char  str  j)  radix)))  ) 

((or  (null  ( d i g i t - cha r - p  (char  str  j)  radix))  (=  j  (length  str)))  n)  )  ) 

(defun  ge t - r i gh t s i de - o f - rea 1  (str  Aoptional  (radix  10)) 

(do  ((index  (1+  ( f i nd - pe r i od- i ndex  str))  (i+  index)) 

(factor  0.10  (*  factor  0.10)) 

(n  00  (+  n  (*  factor  ( d i g i t - cha r -p  (char  str  index)  radix))))  ) 

((=  index  (length  str))  n)  )  ) 


(defun  convert  -  st  i  ing  -  to-  rea  1  (str  •'’•optional  (radix  10)) 

(+  (float  ( ge t -  I e f t s i de - of  -  re  a  1  s;r  radix))  ( ge t  -  r i gh t s i de - of  -  re  a  1  str  radix)) 


(defvar  *iris-portl*  1027) 

(defvar  *iris-port2*  1026) 

(defvar  *  I  oc a  1  - t a  1 k -po r t *  1500) 
(defvar  *  1  oc a  1  -  1 i s t en - po r t *  1501) 


this 

i  s 

t  he 

send  port 

this 

i  s 

t  he 

receive  port 

this 

i  s 

t  he 

local  send  port 

this 

i  s 

the 

local  receive  port 

) 


r-‘ 

>* 

;X 


V 


V 


(defflavor  conver sat ion-wi th-  i  r  i  s  ( (  t a  I  k i ng - por t - numbe r  *  i  r  i  s  -  po r t 1  *  ) 

(  I  istening-port  - numbe  r  *iris-port2*) 

(  I oc  a  1  - ( a  1 k - por  t - numbe  r  *  I oc  a  1  - t  a  I k - po  r  t  * ) 
(local-listen-port- numbe  r  *local- listen-port*) 

( talking-stream) 

(listening-stream) 

( de s t i n a t i on  -  ho s t - ob j e c t  )  ) 

(  ) 

: ini  table- instance-variables  ) 

(  de  fme  t  hod  (  :  i n i t - de  s l i n a t i on  -  ho s  t  conversat ion-wi th- iris) 

(  n  ante  -of  -host  ) 

(setf  de s t i n a t i on - hos t - ob j ec t  (  ne t  : pa r se - hos t  name  -  o f  -  hos t  )  )  ) 
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(defmethod  (:start-iris  conve  r  s  a  t  i  oil  -  wi  t  h  -  i  r  i  s  ) 

(  ) 

(setf  t a  1 k i ng - s t r earn 

(  tcp:open- top- st it  am  dest inat ion-host -object 
talking-port  -  numb  e  r 
1  oca l - t a  1 k - po r t - numbe r  )  ) 

(setf  listening- stream 

( tcp:open- tcp-st  ream  dest inat ion- host -object 
listening- port  -  numbe  r 
1  oca  1  -  1 i s t en - po r t - numbe r  )  ) 

"A  conversation  with  the  iris  machine  has  been  established”  ) 

(defmethod  (:reuse-iris  conve r s a t i on - wi t h - i r i s ) 

(  ) 

) 

(defun  read-string  (stream  num-  chars) 

(let  ( ( ou  t - s  t  r ing  " "  )  ) 

(dotimes  (i  num-chars) 

(setf  out-string  (string-append  out-string  (read-char  sire  am )  )  )  ) 

ou  t - s  t  r i ng  )  ) 

(defmethod  (:get-iris  con ve r s a t i on - wi t h - i r i s ) 

(  ) 

(let*  ((typebuffer  ”  ") 

( I  eng  t  hbu  f  f  e  r  "  " ) 

(buffer  "  "  ) 

( bu f  f  e  r -  1  eng  t  h  1  )  ) 

( progn 

(setf  t  ypebuf  fe  r 

(read-string  I i s t en i ng - s t r e  am  1)  ) 

(setf  1  eng  t  hbu  f  f e  r 

(read-string  1 i s ten ing- s t ream  4)  ) 

(setf  buffer-length 

( conve r t - s t r i ng- to- i n t eger  1  eng t hbu f f e r )  ) 

(setf  buffer 

(read-string  1 i s t en i ng - s t r e am  bu f f e r - 1  eng t h )  ) 

(cond  ((equal  typebuffer  ”1”)  ( conve r t - s t r i ng - t o- i n t ege r  buffer)) 

((equal  typebuffer  "R” )  ( conve r t - s t r i ng- t o- r e a  1  buffer)) 

((equal  typebuffer  "C” )  buffer) 

( t  ni  1  )  )  )  )  ) 

(defvar  *step-var*  0) 

(defun  my- wr i t e - s t r ing( s t r ing  stream) 

(let*  ((num-chars  (length  string))) 

(dotimes  (i  num-chars) 

(write-char  (aref  string  i)  stream)  )  )  ) 

(defmethod  (  : pu t - i  r  i  s  con ve r s a t i on - wi t h - i r i s ) 

(object) 

(let*  ((buffer  (cond 

((equal  (type-of  object)  ’bignum)  ( c on ve r t - numbe r - t o - s t r i ng  object)) 

((equal  (type-of  object)  ’fixnum)  (convert -number- to- s I  ring  object)) 
((equal  (type-of  object)  ' s i ng 1 e - f I oa t )  (convert -number- to- s  t  r ing  object)) 
((equal  (type-of  object)  'string)  object) 

(  t  "error")  )  ) 

( bu f f e r -  1  eng t h  (length  buffer)) 

(typebuffer  (cond  ((equal  (type-of  object)  "bignum)  "I") 

((equal  (type-of  object)  'fixnum)  "'I"') 

((equal  (type-of  object)  ’ s i ng 1 e - f I oa t  )  ”R" ) 

((equal  (type-of  object)  'string)  "C" ) 

( t  "C" )  ) ) 


( length buffer 


(convert -number  - to-st  ring  bu f f e r -  1  eng  I  h  )  )  ) 


Symbolics  irisflavor.lisp 


(progn 

(my -wr i t e - s t r i ng  typebuffer  t a  I k i ng - s t re  am) 

(send  talking-stream  : force- output) 

(if  (=  (length  1  eng t hbu f f e r  )  4) 

(wr i t e - s t r i ng  Teng t hbu f f e r  t a  1 k i ng - s t ream) 

(progn 

(loopfor  *step-var*  (length  1  eng t hbu f f e r )  4 
( wr i t e - s t r ing  "0"  t a  Iking- s t ream)  ) 

(my -wr i t e - s t r i ng  lengthbuffer  t a  1 k i ng - s t r e am)  )  ) 
(send  t alking- s t ream  : f or ce - ou t pu t  ) 

(my -wr i t e - s t r i ng  buffer  t a  1 k . ng - s t r e  am) 

(send  t a  1 ki ng - s t ream  : f or c e - ou t pu t )  )  )  ) 

(defmethod  (:stop-iris  conve r s a t ion- wi t h - i r i s ) 

(  ) 

(progn  (send  t a  1  k i ng - s t r earn  :close) 

(send  1 i s tening- s t ream  :close)  )  ) 


(defun  select-host  (host-name) 

(send  talk  : i n i t - de s t i na t i on  -  ho s t  host-name)  ) 
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APPENDIX  A  -  TEST  AND  UTILITY  PROGRAMS 


1.  gprog.c 


a.  Calling  Protocols 


This  is  a  test  program  for  the  direct  connect  protocol.  By  command  line 
argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 
The  default  is  to  receive  messages  from  iris2.  It  must  be  run  in  conjunction  with 
gprog2.c  to  function  properly,  as  the  port  assignments  are  hardcoded.  Since  it  is  the 
server  program,  it  must  be  started  before  gprog2.c. 


b.  Code  and  Description 

/*  ihis  is  file  gprog.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 
This  is  the  SERVER  side  program  and  runs  first!!!. 


#include  "shared. h" 
#inc 1 ude  ”gl . h" 
^include  "device. h" 


ma  i n( argc , a  rgv ) 

int  argc;  /*  argument  count  */ 

char  *argv[];  /*  pointers  to  the  passed  in  arguments  */ 

( 

Machine  r emo t emach i ne ;  /*  structure  for  remote  machine  */ 

char  o t he r_mach i ne [ 50 ] ;  /*  name  of  other  machine  */ 

char  mybuf fer [LARGESTREAD] ;  /*  received  data  */ 

char  ou t go i ng [LARGESTREAD] ;  /*  outgoing  message's  buffer  */ 

int  mybuf  f  e  r 1 [ LARGESTREAD/ IN I EGER_S I ZE ] :  /*  received  integer  data  */ 

int  ou t go i ng 1 [ LARGESTREAD/ INTEGER_S IZE] ;  /*  outgoing  integer  message's  buffer  */ 

float  mybuf  f  e  r 2 [LARGESTREAD/ FL0AT_S IZE ] ;  /*  received  float  data  */ 

float  ou t go i ng2 [ LARGESTREAD /FL0AT_S IZE] ;  /*  outgoing  float  message  buffer  */ 

long  noutgoing;  /*  size  of  the  outgoing  message  */ 


char  t  emp [10]; 

long  count  =  0; 

char  rece i ved_type( ) ; 

char  t ype_rece i ved ; 

i n  t  el  emen ts_received; 

1 ong  i ; 

long  j  =  0; 
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/*  temp  array  used  to  make  outgoing  message  */ 
/*  message  counter  */ 


/*  temp  loop  variable  */ 

/*  variable  to  control  message  sending  */ 


/*  pull  out  the  string  from  the  argument  list  */ 
i f ( argc  >  2  ) 

I 

pr in t f ( "GPROG:  incorrect  argument  count!  use  gprog  <a 1 i a s>\n"  ) ; 
exi t ( 1 ) ; 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
i  f (  argc  ==  2  ) 

{ 

strcpy(  o t he r_mach i ne  ,  "npscs-"  ); 
strcat(  o t he r_mach i ne  ,  argv[l]  ); 

1 

else 

strcpy(  other_machine ,  " np sc s - i r i s 1 ”  ); 

/*  create  a  path  to  a  particular  machine  (irisl  default)  */ 

/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  fifth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  sixth  argument  is  the  returned  pointer  to  the  structure 
remotemichine  . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 

the  seventh  argument  is  the  amount  of  freespace  desired  for  dynamic 
memory  allocation  during  execution  of  the  program. 

*/ 

dynami  craach i nepa  th( 1 , o t her_mach i ne, l, 2, "server” ,&remot  emach i ne , 2000000) ; 

/*  the  loop  for  polling  the  shared  segment  */ 
while (TRUE) 

( 

/*  make  an  outgoing  message  */ 
s t rcpy( ou t go i ng , "GPROG  ORIGINATED  MESSAGE :  "); 

coun  t  =  coun  t  -  1 ; 

outgoingl[0]  =  count; 

noutgoing  =  s t r 1 en ( ou t go  i  ng  )  ; 

outgoing2[0]  =  count; 


/  *  is  there  data  in  the  shared  se  gme  n  t  ?  * / 
i f( receiver_has_data (&r emo t  emac h i n  e ) ) 

I 

t ype_ rece i ved  =  r ece i ved_ t ype (&r emo t emac h i ne ) ; 
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printf(”The  message  received  by  GPROG  is  of  type  %c  \n" , 
t  ype_rece 1 ved ) ; 

switch  ( t ype_rece i ved ) 

'  case  CHARACTER, ARRAY_TYPE  : 

e 1 emen t s_rece i ved  =  numbe r_r ec e i ved (&r  emo t emach i ne ) ; 

printf(''The  message  received  by  GPROG  is  %d  elements  long!\n" 
e 1 emen  t  s_received); 

read_characters(&remotemachine ,  mybuffer,  element s_received) ; 
break ; 

case  I NTEG  ER_TYPE : 

read, in  t ege  r  (&remo  t  emach ine  .mybuffer 1 ) ; 
break ; 

case  FLQAT_TYPE : 

read, float (&r  emo t  emach i ne .mybuf  f er 2 ) ; 
break ; 

/*  at  this  poim  in  the  program,  process  the  received  data...*/ 
pr in t f (  "GPROG  has  received  the  following  data:\n"): 

switch  ( t ype_rece i ved) 

1  case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  e 1 emen t s_rece i ved ;  i+=l) 

l 

p  r i n  t  f ( "%c  ” .rnybu  fferfi]); 

) 

break; 

case  INTEGER_TYPE : 

pr int f ( "%d" .mybuf  fer 1 [0] ) ; 
break ; 

case  FLQAT_TYPE : 

pr i n  t  f ( "%f  " .mybuf  fe r2 [0] ) ; 
break ; 

I 

pr i n t  f ( ” \n” ) ; 

) 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 
if(sender_is_f  ree(&remo t  emach ine ) ) 

I 

if((j  %  3)  ==  0) 

wr i t  e_charac  t  e  r  s (&remo t  emach i ne , outgoing, n out  going) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! s ende r_ i s_ f ree (&r emo t emach i ne )  )  /*  do  nothing  */  ; 

i f ( ( j  %  3)  ==  1) 

wr  i t  e_ i n  t  ege  r (&r  emo  t  emach ine.outgoingl); 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sende r_ i s_ f r ee (&r emo t erase h i ne )  )  /*  do  nothing  */ 

if((j  %  3)  ==  2) 

wr  i t  e_f I oa  t f&r  emo t  emach ine , ou  t  go i ng2 ) ; 
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2.  gprog2.c 


a.  Calling  Protocols 

This  is  a  test  program  for  the  direct  connect  protocol.  By  command  line 
argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 
The  default  is  to  receive  messages  from  irisl.  It  must  be  run  in  conjunction  with 
gprog.c  to  function  properly,  as  the  port  assignments  are  hardcoded.  Since  it  is  the 
client  program,  it  be  started  after  gprog.c  is  ready  for  it. 

b.  Code  and  Description 

/*  this  is  file  gprog2.c 

It  is  a  sample  top  level  graphics  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

This  is  the  CLIH'IT  side  program  and  runs  second!!!. 

*/ 

#include  "shared. h" 

#define  TRUE  1 


ma  in( argc , argv ) 

int  argc;  /*  argument  count  */ 

char  *argv[];  /*  pointers  to  the  passed  in  arguments  */ 


Machine  remo t  emach i ne  ; 
char  other_machine[50] ; 
char  mybuf f e r [LARGESTREAD] ; 
char  ou  t  go i  ng  [LARGESTREAD]  ; 


/*  structure  for  remote  machine  */ 
/*  name  of  other  machine  */ 

/*  received  data  */ 

/*  outgoing  message's  buffer  */ 


int  mybu f f e r 1 [LARGESTREAD/ INTEGER_S IZE] ;  /*  received  integer  data  */ 

int  ou t go i ng 1 [LARGESTREAD/ INTEGER_S IZE] ;  /*  outgoing  integer  message’s  buffer  */ 

float  mybu f fe r2 [LARGESTREAD /FLOAT_ SIZE] ;  /*  received  float  data  */ 

float  ou t go i ng2 [ LARGESTREAD /FLOAT_S IZE] ;  /*  outgoing  float  message  buffer  */ 

long  noutgoing;  /*  size  of  the  outgoing  message  */ 

char  temp[lO];  /*  temp  array  used  to  make  outgoing  message  */ 

long  count  =  0:  /*  message  counter  */ 

char  rec e  i  ved_ t ype ( ) ; 
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char  t ype_rece i ved ; 
int  e  lemen t s_rece i ved ; 
long  i  : 
long  j  =  0: 


/*  temp  loop  variable  */ 

/*  variable  to  control  message  sending  */ 


/*  pull  out  the  string  from  the  argument  list  */ 
i  f  (  argc  >  2  ) 

I 

p r  i  n t f (  "GPR0G2 :  incorrect  argument  count!  use  gprog2  <alias>\n"): 
exi  t  (  1 ) ; 

1 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
i f (  argc  ==  2  ) 

I 

strcpy(  o t he r_mach i ne ,  "npscs-”  ); 
strcatf  other_machine ,  argv[l]  ); 

I 

else 

strcpy(  o t he r_mach i ne ,  "npscs  iris2”  ); 

/*  create  a  path  to  a  particular  machine  (iris2  default)  */ 

/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  fifth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  sixth  argument  is  the  returned  pointer  to  the  structure 
remot  emach ine  . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 

*1 

machinepath( l.othe  r_machi ne ,2,1, "client” ,&remot  emach ine ) ; 

/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
whi l e (TRUE) 

I 

/*  make  an  outgoing  message  */ 
s t rcpy ( ou t go i ng , " IRIS  1  ORIGINATED  N®SSAGE:  "); 

coun  t  =  coun  t  +  1 ; 

outgoingl[0]  =  count; 

noutgoing  =  s t r  1  en ( ou t go i ng ) ; 

outgoing2(0]  =  count; 

/*  is  there  data  in  the  shared  se  gme  n  1 7  * / 
i f( receiver_has_data(&remot  emach  ine)) 

( 

t  ype_rece  i  ved  =  r ece  i  ved_  t  y pe  (&r emo  t  eniac  h  i  ne  )  ; 

printf("The  message  received  by  IR1S1  is  of  type  %c  \n", 
t  ype_ r ece i ved ) : 

switch  (type  received) 

I 

case  CHARACTER_ARRAY_TYPE : 

e  1  enien  t  s_r  ece  i  ved  =  numbe  r_ re c e  i  ve d (&r  emo t  emac h  i  ne  )  ; 
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printf("The  message  received  by  IR1S1  is  %d  elements  long!\n 
e  1  erne nt  s_received) : 


read_ characters (&remo t  emach i ne  ,mybu  f  f  e  r , 
e  1  emen  ts_received) : 

break; 


case  INTEGER_TYPE : 

read_integer (&remo  t  emach i ne ,mybu  f  f  e  r 1 ) ; 
break; 

case  FLGAT_TYPE : 

read_f 1 oa t (&remo  t  emach i ne ,mybuf  f  e  r2  )  ; 
break ; 

) 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
p r i n t f ! " IRIS  1  has  received  the  following  data:\n"); 

switch  ( t ype_rece i ved ) 

I 

case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  elements  received;  i+=l) 

I 

pr  in  t  f ( "%c" ,mybaf  f e  r [ i ] ) ; 

1 

break; 

case  I NTEG  ER_TYPE : 

p  r i n  t  f  (  "%d "  .rnybu  fferl(OJ); 
break; 

case  FLOAT_TYPE : 

pri nl  f( "%f  " .rnybuf fer2[0j ) ; 
break ; 

) 

p  r  i  n  t  f  (  "  \  n  "  ) ; 

) 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  wi 1 1  send  one  of  three  messages  */ 
i f ( sende  r  i s_f re e  (&remot  emach i ne ) ) 

I 

if((j  %  3)  ==  0) 

wri te_characters (&r emo t  emach i ne, outgoing, noutgoing); 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sende r_i s_f reef&rentot  emach i ne )  )  /*  do  nothing  */  printf("2"); 


if((j  %  3)  ==  1) 

wri te_integer(&r  emo  t  emach ine.outgoingl): 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while!  ! sende r_ i s_f ree !&remot emach i ne  )  )  /*  do  nothing  */  printf("3"); 

i f ( ( j  %  3 )  ==  2 ) 

wri  t  e_  f 1 oa  t  (&r emo  t  emach ine,outgoing2): 


++j ; 

1 

else 

I 

/*  assume  socket  connection  broken  */ 
p r i n t f ( "Sende r  wasn't  free!  Te  rmi na t i ng .  .  . \n "  )  ; 
break: 


a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  iris2.  It  must  be  ran  in  conjunction  with  prog2.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/ *  this  is  file  prog.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 


#include  "shared. h" 
#de  f i ne  TRUE  1 


main( argc , argv ) 

int  argc;  /*  argument  count  +/ 

char  *argv [ ] ;  /*  pointers  to  the  passed  in  arguments  */ 


Machine  remot ernach i ne 1 ; 
Machine  remot emach i ne2 ; 
char  o t he r_mach ine [50] ; 
char  mybuf  f  e  r  [LARGESTREAD] 
char  ou  t  go i  ng  [LARGESTREAD] 


/*  first  structure  for  remote  machine  */ 
/*  second  structure  for  remote  machine  */ 
/*  name  of  other  machine  ♦/ 

/*  received  data  */ 

/*  outgoing  message’s  buffer  */ 


int  mybuf  fer  1  [LARGESTREAD/  INTEGER_S  IZE] 
int  ou  t  go i ng 1 [LARGESTREAD/ IN 1EGER_S IZE ] 
float  mybuf fe r2 [LARGESTREAD/ FLOAT_SIZE] 
float  ou t go i ng2 [LARGESTREAD/ FLOAT_S IZE] 


/*  received  integer  data  */ 

/*  outgoing  integer  message's  buffer  */ 
/  *  received  float  data  *  / 

/ *  outgoing  float  me  ssage  buffer  *  / 


long  n outgoing; 
char  t  emp [10]; 
long  count  =  0: 
char  r e c e i ved_ t ype ( ) ; 
char  type_received; 


/*  size  of  the  outgoing  message  */ 

/*  temp  array  used  to  make  outgoing  message  */ 
/*  message  counter  */ 
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int  element J_received; 

long  i:  /*  temp  loop  variable  */ 

long  j  =  0:  /*  variable  to  control  message  sending  */ 


/*  pull  out  the  string  from  the  argument  list  */ 
if(argc  >  2 ) 

( 

pr in t f ( "PROG :  incorrect  argument  count!  use  prog  <a 1 i as>\n" ) ; 
exi t (  1  )  ; 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

i f (  a lgc  ==  2  ) 

( 

strcpy(  o t he r_mach i ne  ,  argv[l]  ); 

) 

else 

strcpy(  other_machine  ,  "npsc s - i r i s2”  ): 


/*  create  a  pair  of  paths  to  a  particular  machine  (iris2  default)  */ 

/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  receiver  or  a  broadcaster. 

the  seventh  argument  is  the  returned  pointer  to  the  structure 
remot emach ine 1  or  remo t emach i ne2 . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 

*/ 

dyn  ami  emach ine pa t hs( 2 , 1 , o  t  he  r_machi  ne ,2, 1," receive"  ,&remot  emach i ne 1 ) ; 
sleep(5):  /*  to  let  both  sides  set  up  receiving  channels  first  */ 

dyn ami emach inepaths(2, 1 ,othe  r_mach i ne, 4, 3, "broadcast"  ,&remo t  emach  i  ne2 )  ; 


/*  the  loop  for  polling  the  shared  segment  limited  to  avoid  send  buffer 
ove  r  f 1 ow  *  / 
while! TRUE ) 

I 

/*  make  an  outgoing  message  */ 
s t rcpy( out  going , "PROG  ORIGINATED  NESSAGE :  " ) ; 

count  =  coun  t  +  1 ; 

outgoingl[0]  =  count; 

noutgoing  =  s t r 1 en ( ou t go i ng ) ; 

on  t  go  i  ng2  [  !>  ]  =  count; 


/  *  is  there  data  in  the  shared  se  gme  n  t  ?  * / 
i f( receiver_has_data(&r  emot  emach i ne 1 ) ) 

I 

t ype_rece i ved  =  r ece i ved_ t ype (&remo t emach i ne 1 ) ; 

print f( "The  message  received  by  PROG  is  of  type  %c  \n" , 
type_received)  ; 
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( 

case  CHARACTER_ARRAY_TYPE : 

e  lenient  s_received  =  numbe  r_rece  i  ved(&remot  emach  ine  1  )  ; 

printf("The  message  received  by  PROG  is  %d  elements  longlNn' 
e 1 eme  nts_received) : 

read_ characters (&remo  t  emac  h i ne 1 ,mybu  f  f  e  r  , 
e 1 emen  ts_received)  : 

break ; 

case  I NTEG  ER_TYPE : 

re  a d_ integer (Aremot  emach i ne 1  ,mybuf  f e  r  1 )  ; 
break ; 

case  FLOAT_TYPE : 

read_ float  (Aremo  t  emach i ne 1 .mybuf  f  e  r 2  )  ; 
break: 

) 

/*  at  this  point  in  the  program,  process  the  received  data  ...*/ 
printf("PROG  has  received  the  following  data:\n"); 

switch  ( t ype_ r ece i ved ) 

( 

case  CHARAC 1  fciRARRAYTYPE  : 

for(i=0;  i  <  e  1  emen t s_ r ece i ved :  i+=l) 

f 

p  r  i  n  t  f ( "%c" .mybuf  ferfij); 

I 

break; 

case  I  NTEG  ERTYPE  : 

pr  i  n  t  f ( "%d " .mybuf  fe  r 1 [0] ) ; 
break: 

case  FLOATTYPE : 

pr  i n  t  f ( "%f  ” .mybuf  fer2 [0] ) ; 
break; 

I 

p  r  i  n  t  f  (  "  \  n  ”  )  ; 


/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 
if(sender  is_f  ree(&remot  emach ine 2 ) ) 

1 

if((j  %  3)  ==  0) 

wr  i te_cliarac  ters (&r emo  t  emach ine2, outgoing, noutgoing) ; 


/ *  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sende r_ i s_f ree (&r emo t emach i ne2 )  )  /*  do  nothing  print  f("2" )*/ 

i  f  (  (  j  %  3 )  ==  1  ) 

wri  t  e_  i  n  t  ege  r  (Aremo t  emach ine2,outgoingl); 


/*  wait  until  message  sent  before  attempting  to  send  another  */ 

whi  le(  !sender_is_free(Ar emo  t  ema  c  h i n e  2 )  )  / *  do  nothing  p  r i n  t  f ( ” 3 "  )  * / 

i  f ( (  j  %  3  )  ==  2) 

wr  i t  e_  f I oa  t (Aremo t  emach ine2,outgoing2) : 

/ *  wait  until  me  ssage  sent  before  continuing  * / 

whilet  !  s  ende  r_  i  s_  f  ree  (&r  emo  t  eniach  i  ne2  )  )  /*  do  nothing  print  f(."4”  >*/ 


+  +  j  : 

1 

else 
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he 


/*  assume  socket  connection  broken  */ 
printft" Sender  wasn’t  free!\n”  ): 
break: 


/  *  at  this  point,  you  can  do  the  rest  of  the  display  loop  * / 


/*  end  if  while  TRUE  */ 


/*  get  rid  of  the  path  to  the  other  machine...*/ 
de  I  e  t  eniach  i  nepa  t  h  (&r  emo  t  emacli  i  ne  1  )  ; 
de  1  e  t  eniach  1  nepa  t  h  (&r  emo  t  emach  i  ne  2  )  ; 


4.  prog2.c 


a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  iris l .  It  must  be  run  in  conjunction  with  prog.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/*  this  is  file  prog2 . c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  piogram  uses  structure  type  Machine  declared  in  file  shared. h. 

*/ 

#include  " shared. h" 

#dcfine  TRUE  1 


mai n( argc . argv ) 

int  argc;  /*  argument  count  */ 

char  *argv [  ]  ;  /*  pointers  to  the  passed  in  arguments  */ 


Machine  r emo t emach i ne 1 ; 
Machine  r emo  t  emach i ne2 ; 
char  o t he r_mach i ne [ 50 ] ; 
char  mybu  f  f  e  r  [  LARGEST  READ  |  ; 
char  ou t go i ng [LARGESTREAD] ; 


/*  first  structure  for  remote  machine  */ 
/*  second  structure  for  remote  machine  */ 
/*  name  of  other  machine  */ 

/  *  rece  ived  data  * / 

/*  outgoing  message' s  buffer  */ 


int  mybufferl  [LARGESTREAD/  INTEGER_S  IZE } 
int  ou  t  go  i  ng  1  [LARGESTREAD/ INTEGER_S  IZE  ] 
float  mybuffer2[ LARGESTREAD / FLOAT_S I ZE ] 
float  ou t go i ng2 (LARGESTREAD/ FLOAT_S IZE ] 
long  nou  t  go i ng ; 
char  t  emp [10]: 


/*  received  integer  data  */ 

/*  outgoing  integer  message's  buffer 
/  *  received  float  data  *  / 

/*  outgoing  float  message  buffer  * / 
/*  size  of  the  outgoing  message  */ 

/*  temp  array  used  to  make  outgoing  message  * 


long  count  =  0; 
char  r“ceived_type( ); 
char  type_received; 


/*  message  counter  */ 


prog2.c 


i 


« 

.1 

.1 


« 

h. 


i 

» 


i 

I 

« 

1 

1 

H 

H 

». 


int  e l  emen t s_r ece i ved ; 

long  i:  /*  temp  loop  variable  */ 

longj=0;  /*  variable  to  control  me  ssage  sending  * / 


/*  pull  out  the  string  from  the  argument  list  */ 
i f ( a rgc  >  2) 

( 

pr in t f ( "PR0G2 :  incorrect  argument  count!  use  gprog2  <alias>\n"); 
exi t ( 1 ) ; 

) 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
i  f (  a rgc  ==  2  ) 

( 

strcpy(  other  machine,  argvfl]  ); 

I 

else 

strcpy(  other_machine  ,  "npsc s - i r i s2”  ); 


/*  create  a  path  to  a  particular  machine  (iris2  default)  */ 

/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  seventh  argument  is  the  returned  pointer  to  the  structure 
remotemachinel  or  remotemachine2 . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 

*/ 

dynamicmach inepa ths ( 2 , 1 , other _mach ine, 3. 4, "receive"  ,&remot emach i ne2 )  ; 


sleep(5);  /*  to  let  both  ends  of  the  process  get  set  up  */ 
dynamicmach i nepa  t  hs ( 2,1, o t  he  r_mach i ne , 1 , 2 , "broadca  s  t " ,&remot  emach i  ne  l  ) 

/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
while( TRUE ) 

( 

/*  make  an  outgoing  message  */ 
s t repyfoutgoing , "PROG2  ORIGINATED  MESSAGE :  ”); 

coun  t  =  count  +  1 ; 

outgoingl[0]  =  count; 

noutgoing  =  s t r 1 en ( ou t go i ng ) : 

outgoing2[0]  =  count; 

/ *  is  there  data  in  the  shared  se gtne nt?  * / 
i  f(  receiver _h as _d at  a (&r emo t  emach i ne2 )  ) 

I 

t y pe_ r ec e i ved  =  r ece i ved_ t ype (&remo t emach i ne 2 ) ; 

printf("The  message  received  by  PR0G2  is  of  type  %c  \n", 
t  ype_rece i ved ) ; 

switch  ( t y pe_r ec e i ved ) 


TO 
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case  CHARACTER_ARRAY_TYPE : 

e  1  emen  t  s_rece  i  ved  =  numbe  r_ rec e  i  ved(&r emo  t  emach  i  ne2  )  ; 

printf("The  message  received  by  PROG2  is  %d  elements  long!\n 
e 1  erne  nts_received) : 

read_cha  r ac t  e  r  s (&remot  emach i ne2  ,mybu  f  f  e  r  , 
e  1  emen  ts_received)  ; 

break; 

case  INTEGER_TYPE : 

read_ integer (&remo  t  emach i ne2 ,mybu  f  f  e  r 1 ) ; 
break; 

case  FLOAT_TYPE : 

read_ float (&remo  t  emach i ne2 ,mybuf  f  e  r 2 ) ; 
break; 

) 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
p r i n t f ( "PR0G2  has  received  the  following  data:\n"); 

switch  (type  received) 

( 

case  CHARACTERARRAY_TYPE : 

for(i=0;  i  <  e  1  emen t s_r ec e i ved ;  i+=l) 

{ 

p  r i n  t  f ( "%c" ,mybu  ffer[i  ] )  ; 

I 

break; 

case  I NTEG  ER  TYPE ; 

pr  i  n t  f  (  "%d"  ,mybuf  f e  r 1 [0] ) ; 
break; 

case  FLOATTYPE : 

p  r i n  t  f (  "%f " ,my bu  f  f  e  r  2  [  0  ] ) ; 
break; 

) 

print  f  ("\n"  )  ; 

) 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 
if(sender_is_free (&remo  t  emach i ne  1  )  ) 

( 

i  f ( ( j  %  3)  ==  0) 

wri te_characters (&r  emo  t  emach i ne 1 , outgoing, noutgoing) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 

wh  i  1  e (  ! sende r_ i s_ f ree (&r emo t emach i ne 1 )  )  /*  do  nothing  print  f( "2"  )*/ 

if((j  %  3)  ==  1) 

wri  te_integer(&remot  emach inel.outgoingl); 

/  *  wait  until  me  ssage  sent  before  att  emp  ting  to  send  another  *  / 

wh  i  1  e (  ! sende r_i s_f ree (&r emo t emach i ne 1 )  )  /*  do  nothing  print  f("3"  )*/ 

if((j  %  3)  ==  2) 

wri t  e_f 1 oa  t (&r emo  temachinel ,outgoing2)  ; 

/*  wait  until  message  sent  before  continuing  */ 

while!  ! sende r_ i s_f ree (&r emo t  emach i ne 1 )  )  /*  do  nothing  p r i n t f ( " 4"  )  *  / 

++j  ; 

I 

else 
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/*  assume  socket  connection  broken  */ 
p r i n t f ( ” Sende r  wasn't  free!  Terminating, 
break; 

1 


|  I*  e n d i f  while  TRUE  * / 

/*  get  rid  of  the  path  to  the  other  machine 
de  I  e  t  entach  i  nepa  t  h  (&r  emo  t  emacli  i  ne2 )  ; 
de 1 e  t  emach i nepa  t h (&r  emo  t  emach ine  I )  ; 


5.  rmshare.c 


a.  Calling  Protocols 

This  is  a  stand-alone  utility.  It  will  remove  all  shared  memory  segments  owned 
by  the  user.  By  command  line  argument,  selective  segments  can  be  removed. 

b.  Code  and  Description 

/ < 

* 


<******************** 

TITLE 

In  t  e  r -Compu 

NODULE  : 

mis  ha  re  .  c 

VERSION: 

1.0 

DATE 

25  February 

AUTHOR  : 

Theodore  H. 

*  • 

*  HISTORY:  * 

*  * 

*  VERSION: 

*  DATE 
AUTHOR 


1 . 0 

25  February  1988 
Theodore  H.  Barrow 

Removes  shared  memory  segments  identified  on  conmand  line. 


* 

* 

» 

*  DESC. 

* 

*  * 

*  RECORD  OF  CHANGES  * 

*  * 

•Version*  Date  *  Author  *  *  Affected  *Reqd* 

*  *  Change  Description  *  Modules  *Ve r s * 


rmshare 


#include  <errno.h> 

#include  <s y s / s y smac ros . h> 

/(include  <stdio.h> 

# i nclude  <sys/types.h> 

#include  <sys/ipc.h> 

((include  <sys/shm.h> 

#  i  11c  I  ude  <g  1  .  h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

((define  IRIS4D  1 
#de  fine  IRIS3000  2 
(f i f  de  f  FLAT 

#de  fine  MACHINE  IRIS4D 
#e  I  se 

(fde  fine  M\CHINE  IRIS3000 
(fendi f 

extern  int  errno: 
ma  in(  arge,  argv  ) 

int  arge;  /*  argument  count  */ 

char  *argv[];  /*  pointers  to  the  passed  in  arguments  */ 

< 

int  first  =  1 : 
int  last  =  1 000 ; 
key_t  i ; 
int  shmid; 
key_t  key; 

static  struct  shmid_ds  buffer; 


/*  set  the  number  of  shared  memory  keys  to  remove  */ 
i f ( arge  >  1  ) 

I 

for(  i=first;  i<argc;  i++  ) 

I 

key  =  a  t  o i (  a  rgv [  i  ]  ) ; 

iff  (shmid  =  shnigetf  key,  0,  0))  ==  -1  ) 

{ 

if(  errno  !=  ENOENT  ) 

I 

write  error(  shmid,  key,  errno  ); 

I 

I 

else 

I 

iff  shmctl(  shmid,  IPC_RMID,  &buffer  )  ==  -  1  ) 
1  . 

write_error(  shmid.  key,  errno  ) : 

1 

else 

write_done(  shmid,  key  ); 

I  I*  if(  (shmid  =  shmget(  i,  0,  0  ))  ==  -1  )  */ 

I  /*  for  ♦/ 

I 

else 

I 

fort  i=first;  i clast;  i++  ) 

I 

if(  (shmid  =  shmget(  i,  0,  ()))  ==  -1  ) 

I 

if(  errno  !=  ENOENT  ) 

I 

wri!e_error(  shmid.  i,  errno  ); 

1 


r  ms  hare 


if(  shmctl(  shmid.  IPC_RMID,  &buffer  )  == 


write_error(  shmid,  i,  errno  ); 


else 

write_done(  shmid,  i  ); 

)  /*  if(  (shmid  =  shmget(  i,  0,  0  ))  ==  -1 

)  /*  for  */ 


print  f (  " \ nComp 1 e  t  e  d . \n "  ) ; 


)  /*  main(  )  * / 


write_error(  shmid,  key,  error  ) 
int  shmid: 
key_t  key: 
int  error; 


print  f (  "\nShared  Memory  ID  %d  (key  %d)  caused  error  %d . ” , 
shmi d ,  key ,  error  ) ; 


)  /*  wr i t e_e r ro r (  )  */ 


write_done(  shmid,  key  ) 
int  shmid; 
key_t  key; 


printf(  "\nSha red  Memory  ID  %d  (key  %d)  removed.",  shmid,  key  ); 


|  / *  wr i t  e_done ( )  * / 


V  *>  V  *>  V  O  V'. 
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6.  testshare.c 

a.  Calling  Protocols 

This  is  a  stand-alone  utility.  It  will  print  current  parameters  for  all  active 
shared  memory  segments.  By  command  line  argument,  selective  segments  can  be 
printed. 

b.  Code  and  Description 


*  * 
*  TTTT.F.  Tnfer-Cnmnuf  er  ffimniin  i  ca  t  i  on  Pack  nae  * 


$ 

$ 


5S 

1 

i 


m. 


*  TITLE 

* 

*  MODULE 

* 

*  VERSION 

* 

*  DATE 

* 

*  AUTHOR 

* 


In  t  e  r -Compu  t  e  r  Coftmun  i  c  a  t  i  on  Package 

testshare.c 

1.0 

25  February  1988 
Theodore  H.  Barrow 


RECORD  OF  CHANGES 


•Version*  Date  *  Author  *  *  Affected  *Reqd* 

*  *  Change  Description  *  Modules  *Vers* 


testshare.c 

#inclu<le  <errno.h> 

#include  <sy s / sy smac ros . h> 

#  include  <sldio.h> 

#include  <s y s / t ype s . h> 

^include  <sys/ipc.h> 

# include  <s  y  s  /  s  inn.  h> 

# i nc 1 ude  <g 1 . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#de  f i ne  IRIS4D  1 
# d e f i n e  IRIS3000  2 
#i fdef  FLAT 

#de  f i ne  MACHINE  IRIS4D 
#e  1  se 

#de  fine  MACHINE  IRIS3000 
#endi f 

extern  int  err no; 
ma  i  n (  ) 

I 

int  first  =  1 ; 
int  last  =  1000 ; 
int  i  ; 
int  shmid; 


for(  i  =  first;  i < 1  a  s  t ;  i++  ) 

I 

if(  (shmid  =  shmgetf  i,  0,  0))  ==  -1  ) 

I 

if(  errno  !=  ENOENT  ) 


( 


write_error(  shmid,  i,  errno  ); 


I 


e  1  se 

I 

if(  wr i t e_s t rue t (  shmid  )  ==  - 1  ) 
write_error(  shmid,  i,  errno  ); 

)  /*  if(  (shmid  =  s  lunge  t(  i,  0,  0  )) 

1  /•  for  */ 


-1  )  */ 


printf(  "\ nComp 1  e  t  e  d  .  \  n " 
/*  main! )  */ 


)  ; 


writ  e_er ror(  shmid,  key,  error  ) 
int  s  hm  i  d  ; 
key_ t  key: 
int  error; 


print  f (  "\nShared  Memory  ID  %d  (key  %d )  caused  error  %d  . 
shrni d,  key,  error  ); 

/ *  write_error()  * / 


struct  shmid_ds  *get_struct(  slunid  ) 
int  s  lull  i  d  ; 


static  struct  shrni  d_ds  buffer; 

i  f (  shmctl(  shmid,  IPC_STAT,  &buffer  )  ==  -  1  ) 


testshare.c 


(struct  shmid_ds  *)-l  ): 

&bu  f  f  e  r  )  ; 

I  / *  ge t_s  t  rue  t (  )  * / 

wr  i  t  e_  s  t  rue  t  (  slimid  ) 
i  n  t  s  hmi  d : 


r  e  t  u  r  n  ( 
I 

else 

return! 


struct  shmid_ds  *buf; 

if(  (int)(buf  =  get_struct(  shmid  ))==-!  ) 
ieturn(  (int)buf  ); 


p  r  i  n  t  f  ( 

"NnShared  Memory  ID  % 

p  r  i  n  t  f  ( 

"\n 

shm_perm  has  th 

p  r  i  n  t  f  ( 

"\n 

c  u  i  d  is  %d  .  ” 

print  f  < 

"\n 

c  g i d  is  %d  .  " 

p  r  i  n  t  f  ( 

"  \n 

u i d  is  %d . " , 

p  r  i  n  t  f  ( 

M\n 

g i d  is  %d  . "  , 

p  r  i  n  t  f  ( 

"  \n 

mode  i s  %o . " 

p  r  i  n  t  f  ( 

"  \n 

seq  is  %d  . "  , 

p  r  i  n  t  f  ( 

"  \n 

key  is  %d  . " , 

print  f ( 

"  \  n 

s hm_ segsz  is  %d 

p  r  i  n  t  f  ( 

"  \n 

s  hm_  r  e  g  is  a  s  t 

p  r  i  n  t  f  ( 

'*  \n 

s hm_  1 p i d  is  %d . 

p  r  i  n  t  f  ( 

"  \n 

shm_cp  i  d  i  s  %tl . 

pr i nt  f ( 

"  \n 

slim_nat  tch  i  s  % 

pr  i  n  t  f  ( 

"\n 

shm_cnat  tch  is 

p  r  i  n  t  f  ( 

M\n 

slmi_atime  is  %d 

pr i n  t  f ( 

”\n 

shm  dt  ime  i  s  %d 

p  r  i  n  t  f  ( 

”  \n 

shm_c  t  ime  i  s  %d 

I  has  the  following  structure:",  slimid  )  ; 

:  following  structure:"  ); 

bu f -> s hm_pe rm. cu i d  ); 

,  bu f ->s  hm_pe  rm  eg  id  ); 
bu f ->shm_pe  mi. u i d  ); 
bu f ->shm_pe rm. g i d  ); 

bu f - >s hm_pe rm.mode  ); 
buf->slim_perm.  seq  ); 
bu f ->shm_pe rm. key  ); 

o  r  %x  .  "  ,  b  u  f  -  >  s  lim_  segsz,  buf->s  hm_  s  e  g  s  z  ) 
ructure  incompletely  defined  in  region. h!" 
'  ,  bu  f  -  >  shm_  1  p  i  d  )  ; 

bu f ->shm_cp i d  ); 

1.",  buf ->shm_nat tch  ); 

%d  . " ,  buf ->shm_cna t t ch  ); 
bu  f ->s  hni_a  t  ime  ): 
buf ->shm_dt  ime  ) 
buf ->shm_segsz  ) 


return!  0  ) ; 
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